Re: [arch-dev-public] Trimming down our default kernel configuration
On 28.03.2014 06:25, Connor Behan wrote: > [...] Not sure why, but your last 2 replies to the thread refer to message IDs I don't have (mailman.*.arch-dev-public@archlinux.org) so threading is broken. Are you replying to digest posts? signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
Am 28.03.2014 06:25, schrieb Connor Behan: > On 27/03/14 08:24 AM, tho...@archlinux.org wrote: >> Am 27.03.2014 09:52, schrieb Connor Behan: >>> On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: > Looks like audit is still built into our kernel. Wasn't this meant to be > reverted as well? Forgot about that. That was pulled in by AppArmor or so. >>> Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact >>> that community/audit came out shortly after? >> No, it was pulled in accidentally as a dependency of AppArmor. > I doubt that. AppArmor was enabled a year and a half after audit was. > > https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=e46bc1d41848b258a138df26590967dc1e0a3417 > > https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=688e0f7508fa943868470e9d6c0dcb12823b06f0 Yeah, that was incorrect in my memory. It was actually SELinux that pulled it in. >> If we actually want audit, we should support it as well. Our systemd >> package is compiled with -AUDIT for example. >> >> Since audit is one of those "enabled unless the user intervenes" option >> that also does annoying things, I would like to get rid of it in our kernel. > It is supported if you count [community] packages. I'll ask on the LKML > if anything can be done about the logging. It's not about logging, it's about being enabled by default when it is supported by the kernel. There's no "disable audit by default" switch. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On 27/03/14 08:24 AM, tho...@archlinux.org wrote: > Am 27.03.2014 09:52, schrieb Connor Behan: >> On 27/03/14 01:07 AM, tho...@archlinux.org wrote: >>> Am 26.03.2014 20:08, schrieb Dave Reisner: Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well? >>> Forgot about that. That was pulled in by AppArmor or so. >> Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact >> that community/audit came out shortly after? > No, it was pulled in accidentally as a dependency of AppArmor. I doubt that. AppArmor was enabled a year and a half after audit was. https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=e46bc1d41848b258a138df26590967dc1e0a3417 https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=688e0f7508fa943868470e9d6c0dcb12823b06f0 > If we actually want audit, we should support it as well. Our systemd > package is compiled with -AUDIT for example. > > Since audit is one of those "enabled unless the user intervenes" option > that also does annoying things, I would like to get rid of it in our kernel. It is supported if you count [community] packages. I'll ask on the LKML if anything can be done about the logging. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 09:52, schrieb Connor Behan: > On 27/03/14 01:07 AM, tho...@archlinux.org wrote: >> Am 26.03.2014 20:08, schrieb Dave Reisner: >>> Looks like audit is still built into our kernel. Wasn't this meant to be >>> reverted as well? >> Forgot about that. That was pulled in by AppArmor or so. > Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact > that community/audit came out shortly after? No, it was pulled in accidentally as a dependency of AppArmor. If we actually want audit, we should support it as well. Our systemd package is compiled with -AUDIT for example. Since audit is one of those "enabled unless the user intervenes" option that also does annoying things, I would like to get rid of it in our kernel. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On 27.03.2014 10:08, Massimiliano Torromeo wrote: > I didn't know when it was added in the kernel or why, but I find it useful > and would appreciate it being kept in (that's why I maintain > community/audit). If it wouldn't log all kinds of new session stuff (I guess those are all ssh logins) to dmesg even if you don't use auditd. So far the only way I found to get rid of all those messages is to either install and start auditd and disable then audit or to add audit=0 or something to the kernel line. I don't like either. If it could be enabled but default to not logging anything I'd be happy. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 9:52 AM, Connor Behan wrote: > On 27/03/14 01:07 AM, tho...@archlinux.org wrote: > > Am 26.03.2014 20:08, schrieb Dave Reisner: > >> Looks like audit is still built into our kernel. Wasn't this meant to be > >> reverted as well? > > Forgot about that. That was pulled in by AppArmor or so. > Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact > that community/audit came out shortly after? I didn't know when it was added in the kernel or why, but I find it useful and would appreciate it being kept in (that's why I maintain community/audit).
Re: [arch-dev-public] Trimming down our default kernel configuration
On 27/03/14 01:07 AM, tho...@archlinux.org wrote: > Am 26.03.2014 20:08, schrieb Dave Reisner: >> Looks like audit is still built into our kernel. Wasn't this meant to be >> reverted as well? > Forgot about that. That was pulled in by AppArmor or so. Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact that community/audit came out shortly after? signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On Wed, Mar 26, 2014 at 06:53:43PM -0400, Daniel Micay wrote: > On 26/03/14 02:56 PM, Thomas Bächler wrote: > > Hello all, > > > > it won't be too long until 3.14 is out and I want to address a topic > > that has been bugging me for a while. Our kernel includes everything and > > the kitchensink. I have no problem with delivering drivers that can be > > built modular, but there are other things that have an unknown impact on > > everyone. > > > > I want to trim our kernel down to what we actually support. > > I think we should drop x32 support if no one is planning on packaging > the minimum of a compiler and standard C library. It's cool, but no one > appears to be very interested in using it in the real world. You would > probably get bigger wins from recompiling with -march=native, so I > somewhat doubt that anyone grasping for the last bit of performance will > use our binaries anyway. > > This was already responsible for a security vulnerability in Arch: > > http://seclists.org/oss-sec/2014/q1/187 > Ah, I knew I forgot something from my last email. Yes, x32 should go away if we aren't interested in hosting the toolchain for it.
Re: [arch-dev-public] Trimming down our default kernel configuration
On 26/03/14 02:56 PM, Thomas Bächler wrote: > Hello all, > > it won't be too long until 3.14 is out and I want to address a topic > that has been bugging me for a while. Our kernel includes everything and > the kitchensink. I have no problem with delivering drivers that can be > built modular, but there are other things that have an unknown impact on > everyone. > > I want to trim our kernel down to what we actually support. I think we should drop x32 support if no one is planning on packaging the minimum of a compiler and standard C library. It's cool, but no one appears to be very interested in using it in the real world. You would probably get bigger wins from recompiling with -march=native, so I somewhat doubt that anyone grasping for the last bit of performance will use our binaries anyway. This was already responsible for a security vulnerability in Arch: http://seclists.org/oss-sec/2014/q1/187 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On 26/03/14 03:08 PM, Dave Reisner wrote: > On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler wrote: >> Hello all, >> >> it won't be too long until 3.14 is out and I want to address a topic >> that has been bugging me for a while. Our kernel includes everything and >> the kitchensink. I have no problem with delivering drivers that can be >> built modular, but there are other things that have an unknown impact on >> everyone. >> >> I want to trim our kernel down to what we actually support. > > +1 > >> 1) Once we agreed to disable one LSM, everyone else said "we can enable >> LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK, >> Tomoyo, AppArmor and Yama, although we don't support the userspace for >> any of those. >> >> I propose to drop all of them. > > Very much agreed. Though, I wouldn't mind if we kept yama around in some > disabled form if possible. There's no userspace component here, just the > ptrace_scope knob in sysctl, which a lot of other distros enable. It > affects a rather small number of app, but potentially closes off a > fairly large security concern. I think we should keep Yama, because it's a simple knob providing a significant security boost without any integration into our packages. It's an especially nice improvement to many of our services able to run in a chroot, but not yet aware of process namespaces. Yama previously included knobs for protected symlinks and hardlinks, and those became core kernel features. It doesn't really make sense to me that this tiny feature was forced to be an LSM module... it was originally authored as a built-in sysctl switch and perhaps it will move in the future too. If someone wants to support the userspace component of a *non-invasive* (no patches) LSM module in [extra] or [community] down the road, then enabling it would make sense. We're never going to have good SELinux integration, and haphazard patches and policies from the AUR are only going to do more harm than good. >> 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without >> enabling CONFIG_EXPERT. I have no idea what the impact of this option >> is, other than that it was requested in order to support some tool that >> can freeze and save single processes resume them later. I am generally >> sceptical towards options that require CONFIG_EXPERT, so I propose >> dropping this one, too. > > CRIU userspace tools are in the AUR. +1 to dropping this unless we have > someone to wants to actually maintain this in the repos. I don't think this actually works properly with our kernel, as I played with it and just got a bunch of broken snapshots. I thought about moving it to [community] in the past, but Mozilla's rewindable debugger has erased any interest I once had in it: http://robert.ocallahan.org/2014/03/introducing-rr.html signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On 03/26/2014 07:56 PM, Thomas Bächler wrote: > 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without > enabling CONFIG_EXPERT. I have no idea what the impact of this option > is, other than that it was requested in order to support some tool that > can freeze and save single processes resume them later. I am generally > sceptical towards options that require CONFIG_EXPERT, so I propose > dropping this one, too. I'm trying to make use of it since 3.13 and I can't recall if even pre-dump worked fine at least once, so +1. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
Am 26.03.2014 20:08, schrieb Dave Reisner: > Looks like audit is still built into our kernel. Wasn't this meant to be > reverted as well? Forgot about that. That was pulled in by AppArmor or so. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler wrote: > Hello all, > > it won't be too long until 3.14 is out and I want to address a topic > that has been bugging me for a while. Our kernel includes everything and > the kitchensink. I have no problem with delivering drivers that can be > built modular, but there are other things that have an unknown impact on > everyone. > > I want to trim our kernel down to what we actually support. +1 > 1) Once we agreed to disable one LSM, everyone else said "we can enable > LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK, > Tomoyo, AppArmor and Yama, although we don't support the userspace for > any of those. > > I propose to drop all of them. Very much agreed. Though, I wouldn't mind if we kept yama around in some disabled form if possible. There's no userspace component here, just the ptrace_scope knob in sysctl, which a lot of other distros enable. It affects a rather small number of app, but potentially closes off a fairly large security concern. > 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without > enabling CONFIG_EXPERT. I have no idea what the impact of this option > is, other than that it was requested in order to support some tool that > can freeze and save single processes resume them later. I am generally > sceptical towards options that require CONFIG_EXPERT, so I propose > dropping this one, too. CRIU userspace tools are in the AUR. +1 to dropping this unless we have someone to wants to actually maintain this in the repos. > 3) We enable tons of debug options in the "Kernel Hacking" section, many > of which have a "small performance impact". I'd like to get rid of those > that we don't need (I didn't go through all of them yet). > > What I'd like is a discussion where people suggest more things that > could or should be dropped, and tell me what is absolutely needed and > why. I hope that such a discussion makes it clearer to me how I should > proceed. Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well?
[arch-dev-public] Trimming down our default kernel configuration
Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said "we can enable LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without enabling CONFIG_EXPERT. I have no idea what the impact of this option is, other than that it was requested in order to support some tool that can freeze and save single processes resume them later. I am generally sceptical towards options that require CONFIG_EXPERT, so I propose dropping this one, too. 3) We enable tons of debug options in the "Kernel Hacking" section, many of which have a "small performance impact". I'd like to get rid of those that we don't need (I didn't go through all of them yet). What I'd like is a discussion where people suggest more things that could or should be dropped, and tell me what is absolutely needed and why. I hope that such a discussion makes it clearer to me how I should proceed. Regards Thomas signature.asc Description: OpenPGP digital signature
