[arch-general] 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
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler <thomas@archlinux.org> 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.
Thanks for doing this.
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.
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
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
Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that.
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that.
But by default, kernel.yama.ptrace_scope = 0, which according to documentation (Yama.txt) is like having no ptrace restriction at all, and indeed gdb/strace work... Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Am 26.03.2014 21:31, schrieb Leonid Isaev:
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that.
But by default, kernel.yama.ptrace_scope = 0
No. The default is 1.
On Wed, 26 Mar 2014 22:17:25 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.03.2014 21:31, schrieb Leonid Isaev:
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.03.2014 20:18, schrieb Leonid Isaev:
However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that.
But by default, kernel.yama.ptrace_scope = 0
No. The default is 1.
Yes, you are right, I was speaking from the old memory... If this causes problems and a default sysctl.d/ conf file is not desired, then I guess, Yama can go away as well. Does this discussion also apply to the -lts kernel? Thanks, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 26-03-2014 19:18, Leonid Isaev wrote:
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.
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing).
However, I don't think that Yama requires any userspace components, does it? Currently, I boot with "security=yama" and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do).
If the reason for dropping support is the lack of maintained userspace tools then tomoyo does have tomoyo-tools in [community]. However it requires the user to manage rules creation and maintenance. -- Mauro Santos
Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev <lisaev@umail.iu.edu>:
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler <thomas@archlinux.org> 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.
Thanks for doing this.
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.
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing).
I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind "why nobody hasn't asked yet to make libselinux and libsepol official packages?" is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways : a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config. Regards, Nicolas [1] https://github.com/Siosm/siosm-selinux [2] https://github.com/fishilico/selinux-refpolicy-patched [3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261 [4] https://wiki.archlinux.org/index.php/SELinux [5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32
I think what Nicolas says is a good idea. I realise that Arch is not really a security-focused distro, but having to not recompile the kernel on my laptop after every upgrade with SELinux enabled is a pretty awesome thing. I realise that this is not really relevant to most Archers, but with Siosm working on a working Arch SELinux Policy, I think that having something like the SELinux LSM is not really a burden on the user. On the other hand, (seeing that it has come up) a package like linux-sources would be wonderful. In short, I think that for something as essential as the kernel, having multiple configurations (viz. linux, linux-lts, linux-light and linux-sources) in the official repos is a pretty good idea. I hope it can be realised. On Thu, Mar 27, 2014 at 5:07 PM, Nicolas Iooss <nicolas.iooss@m4x.org>wrote:
Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev <lisaev@umail.iu.edu>:
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler <thomas@archlinux.org> 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.
Thanks for doing this.
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.
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing).
I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind "why nobody hasn't asked yet to make libselinux and libsepol official packages?" is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3].
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel.
That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways :
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config.
Regards,
Nicolas
[1] https://github.com/Siosm/siosm-selinux [2] https://github.com/fishilico/selinux-refpolicy-patched [3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261 [4] https://wiki.archlinux.org/index.php/SELinux [5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32
-- Savyasachee Jha *"Without a sign his sword a brave man draws, And asks no omen but his country's cause."*
On Thursday 27 Mar 2014 09:07:23 Nicolas Iooss wrote:
c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5].
One of my machines requires a patched kernel, but I've never felt the need for a linux-src package. I use Yaourt as an ABS client, but there are others available: # yaourt -G linux # cd linux --- do patching --- # makepkg The PKGBUILD even contains instructions on how to tweak the configuration, if I remember correctly. Paul
Am 27.03.2014 09:07, schrieb Nicolas Iooss:
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing).
I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind "why nobody hasn't asked yet to make libselinux and libsepol official packages?" is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3].
You use AUR packages for all kinds of SELinux stuff, so why not use a custom kernel for that?
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux.
So, installing packages from AUR is easy, _except_ when you need to install the kernel?
This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux.
So, install a kernel from unofficial repositories or AUR? It's "just a package".
* Second, it's possible to compile things which are disabled at runtime.
That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's "only" a performance impact and at worst, it even causes problems. The whole idea is to make the kernel smaller and to avoid problems caused by things we don't make use of.
Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work.
Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask "are we using LSM xyz?". In any case, it's more code and thus more room for failure. I see where you are coming from and I used to think the same way. But after we enabled AppArmor and SELinux in 3.13, the audit subsystem was silently enabled - and it is _on_ by default. This whole story got me thinking, do we even have any idea what the consequences of adding these features are? And I don't think we do. The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core. I don't have a really strong argument against these options, except that once we enable them, we need to deal with problems that they may cause users. I think we are better off going with what the majority of Arch users use these days (simple DAC LSM) and let everyone else deal with their use case themselves.
* Third, users who want to combine several unofficial features for their kernel already have to do weird things.
Users competent enough to do weird things can compile their own kernels.
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config.
I won't maintain two kernels just for the sake of feature-creep.
c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5].
What is this supposed to do? Makepkg is for building packages, pacman is for installing binaries. If you want automated package building on upgrades, use Gentoo.
d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 27.03.2014 13:46, schrieb Thomas Bächler:
Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask "are we using LSM xyz?". In any case, it's more code and thus more room for failure.
Not necessarily, i do not know the code of all the policy enforcement points, but if you have a function pointer to the policy decision function, you only have to query this function. So if you enable SELinux, you let the pointer point to the SELinux function. Maybe you don't understand what i mean because of my bad english, here an example code: int (*func)( char *arg, ... ); int SELinux_pdp( char *arg, ... ) { Code } int pdp( char *arg, ... ) { Code } if( SELinux ) { func = &SELinux_pdp; } else { func = &pdp; } So you only have to call func( arg, ... ) and test the returned value. Besides that, i'd prefer a smaller kernel, too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlM0NKkACgkQkr64biT2RYQzegD+MU+yBgTPoIA0RB9CH9l2CFpp dEEGg5FfYVdodSYtAGsA/jOmUhnz+DvogZDYVHpsPmjObexou6qcGRpJPMxIL8jK =igbX -----END PGP SIGNATURE-----
Am 27.03.2014 15:24, schrieb Simon Brand:
Am 27.03.2014 13:46, schrieb Thomas Bächler:
Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask "are we using LSM xyz?". In any case, it's more code and thus more room for failure.
Not necessarily, i do not know the code of all the policy enforcement points, but if you have a function pointer to the policy decision function, you only have to query this function. So if you enable SELinux, you let the pointer point to the SELinux function.
Do you know that Linux operates this way? If so, at least we don't have to assume that performance suffers. This again begs the question, why do the LSMs need to be built-in? Why can't they be modular? I don't expect you to answer these questions, they are just things that I consider. Perhaps let me rephrase my rationale: If we include support for an LSM in Linux, it should be because we support it in our user-space, too. I don't see SELinux being supported by default in Arch anytime soon. _If_ at some point we make a decision to support it (optional or by default), we can enable it in the kernel. The whole idea of trimming down the kernel is to stop enabling things because some users _may_ _possibly_ want to use them.
TL;DR: this is a technical answer which can be seen as slightly off-topic as it focus only on SELinux and not much about kernel config trimming. 2014-03-27 13:46 GMT+01:00 Thomas Bächler <thomas@archlinux.org>:
Am 27.03.2014 09:07, schrieb Nicolas Iooss:
I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing).
I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind "why nobody hasn't asked yet to make libselinux and libsepol official packages?" is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3].
You use AUR packages for all kinds of SELinux stuff, so why not use a custom kernel for that?
Because there is a chicken-and-egg issue here. The long term motivation is to migrate SELinux-compiled duplicated packages (like sudo, systemd...) from the AUR to official packages ("long term" meaning "no timeline can be given as there are way too many people against it"). Currently there is a security issue due to package duplication in the AUR (when a security patch is made for systemd for example, it takes some time before systemd-selinux is updated). I won't discuss this more in this thread as it is off topic.
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux.
So, installing packages from AUR is easy, _except_ when you need to install the kernel?
Yes, because there is no easy way to "mix two packages". I don't know any other software which is provided in different packages depending on their configuration. Most Archlinux packages support via configure-time switches many things I've never heard about. Why would it be different for the kernel? (I'm expecting people to ask me this question and as I don't have any relevant answer yet, I ask it here.)
This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux.
So, install a kernel from unofficial repositories or AUR? It's "just a package".
If you installed modules with DKMS, you also need to recompile these modules and it may break. I agree that "it's just a package" and "nothing should break", but that's just theory and in the real world, things like unsupported DKMS modules break with a custom kernel and this increases the difficulty a lot. However this increases the maintenance burden of unsupported things so it's not relevant here.
* Second, it's possible to compile things which are disabled at runtime.
That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's "only" a performance impact and at worst, it even causes problems. The whole idea is to make the kernel smaller and to avoid problems caused by things we don't make use of.
Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work.
Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask "are we using LSM xyz?". In any case, it's more code and thus more room for failure.
According to http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security... and http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security... , the security checks are done using a structure of function pointers (struct security_operations *security_ops) and the execution path to check a file permission (at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/read_... for example) looks exactly the same in both "SELinux not compiled" and "SELinux compiled but disabled" configurations. I may have misunderstood the code, in such case I'd be glad if you correct me.
I see where you are coming from and I used to think the same way. But after we enabled AppArmor and SELinux in 3.13, the audit subsystem was silently enabled - and it is _on_ by default. This whole story got me thinking, do we even have any idea what the consequences of adding these features are? And I don't think we do.
This does sound weird. Could you please give me some references to this so that I can understand better? I only know that SELinux uses the audit subsystem to report denials and that the audit subsystem can be disabled at boot time using "audit=0" kernel command line parameter (and also I've read http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/a...).
The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core.
I don't have a really strong argument against these options, except that once we enable them, we need to deal with problems that they may cause users. I think we are better off going with what the majority of Arch users use these days (simple DAC LSM) and let everyone else deal with their use case themselves.
So, if I understand correctly, your opinion is to restrict as most as possible the official/supported basis and force "experienced" users use unsupported packages to do unsupported things. That makes sense and "distributes" the work between official package maintainers and AUR package mainteners. I completely agree with a position which aims to give less work to everyone by distributing the user support.
* Third, users who want to combine several unofficial features for their kernel already have to do weird things.
Users competent enough to do weird things can compile their own kernels.
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config.
I won't maintain two kernels just for the sake of feature-creep.
c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5].
What is this supposed to do? Makepkg is for building packages, pacman is for installing binaries. If you want automated package building on upgrades, use Gentoo.
Why talking about Gentoo? Using yaourt -G and makepkg is enough for building kernels with a custom config (thanks, Paul). (By the way, I also administrate Gentoo and Debian servers but the reasons why I still use Arch is off-topic). The more I'm thinking of it and the more I wonder why the "light kernel" wouldn't be an AUR package, so that users who really want a light kernel can easily compile it themselves? Maybe it even already exists and nobody has taken time to find it before starting the discussion? I don't know if the approach "do it in the AUR and then ask users to test it before asking devs to integrate changes in official packages" is common/relevant. Thanks, Nicolas
Am 27.03.2014 20:33, schrieb Nicolas Iooss:
TL;DR: this is a technical answer which can be seen as slightly off-topic as it focus only on SELinux and not much about kernel config trimming.
Very interesting, thanks for looking into it deeper. I'll leave most of this uncommented.
This does sound weird. Could you please give me some references to this so that I can understand better? I only know that SELinux uses the audit subsystem to report denials and that the audit subsystem can be disabled at boot time using "audit=0" kernel command line parameter (and also I've read http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/a...).
Okay, you are right, it wasn't AppArmor, it was SELinux. According to Kconfig, SELinux depends on Audit. And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. As long as SELinux needs audit and audit is enabled by default, SELinux will not make it to the 3.14+ versions of our linux package.
Hi, În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line.
I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact. Kernel debugging options on the other side seem to have a much bigger impact. It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled. People in this thread like to put out the over subjective "lightweight" factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back. The facts will remain though: * the kernel will still be "everything and the kitchen sink". * no provable performance enhancement so far. * security measures will get back at square 1. ¹ http://www.phoronix.com/scan.php?page=article&item=fedora_debug_selinux ² https://dl.dropboxusercontent.com/u/29107946/Assessing-the-Performance-Impac... As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here. -- Arthur Țițeică
On Fri, Mar 28, 2014 at 11:54 AM, Arthur Țițeică <arthur@psw.ro> wrote:
Hi,
În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line.
I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact.
Kernel debugging options on the other side seem to have a much bigger impact.
It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled.
People in this thread like to put out the over subjective "lightweight" factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back.
Exactly my thoughts about this thread. http://i.imgur.com/nfFuu.jpg I'm very much for cleaning up the kernel config from things that factually are useless. Thanks for reading up everyone and keep trying to not step on each other's toes. cheers! mar77i
On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote:
I'm very much for cleaning up the kernel config from things that factually are useless.
"Factually useless" is not a subjective standard by which to measure things. If you don't personally configure the features in question by installing third-party userspace packages then they are, in fact, useless to you. If you don't contribute code to the kernel, the kernel debugging features (which eat up a lot of build time) are almost certainly, in fact, useless to you. Such is the case for everything found in the kernel: Someone, somewhere will find it useful, and that's a fact. Whether the majority of Arch users find it useful, and it therefore should be maintained by a limited staff with limited resources, is what's in question here. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
On Fri, Mar 28, 2014 at 2:40 PM, Bigby James <bigby.james@crepcran.com> wrote:
On Fri, Mar 28, 2014 at 12:01:06PM +0100, Martti Kühne wrote:
I'm very much for cleaning up the kernel config from things that factually are useless.
"Factually useless" is not a subjective standard by which to measure things. If
I fully agree. Neither is common sense, obviously.
you don't personally configure the features in question by installing third-party userspace packages then they are, in fact, useless to you. If you
Well, they came in when people argued in favor of them. [0]
don't contribute code to the kernel, the kernel debugging features (which eat up a lot of build time) are almost certainly, in fact, useless to you. Such is the
I guess we all agree about the debugging features.
case for everything found in the kernel: Someone, somewhere will find it useful, and that's a fact. Whether the majority of Arch users find it useful, and it therefore should be maintained by a limited staff with limited resources, is what's in question here.
If a justifiable amount of effort saves a significant amount of time and energy for the few people who use it, I'm in favor of the security features being there so I have them at my disposal in case I would decide to experiment with them one day too. The hurdle to consider such features is higher if they aren't in the official kernel, as building a kernel takes time and caution. What will actually happen is fully that person's decision who will or will not implement change. And no, I'm not aware of any decisions around Arch needed any kind of majority. Good day. mar77i [0] https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.ht...
On Fri, Mar 28, 2014 at 03:05:25PM +0100, Martti Kühne wrote:
Well, they came in when people argued in favor of them. [0]
[0] https://mailman.archlinux.org/pipermail/arch-general/2013-November/034385.ht...
That entire thread regards the userspace packages and the kludge of a policy that are in the AUR, and about the fact that they weren't even being properly maintained. It doesn't refer to the in-kernel modules/code.
If a justifiable amount of effort saves a significant amount of time and energy for the few people who use it, I'm in favor of the security features being there so I have them at my disposal in case I would decide to experiment with them one day too.
So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that "one day" is a year from now? Two years? And what if your time spent "experimenting" leads you to conclude that these things are "factually useless" to you? What then of the effort the devs put into it? As I mentioned above regarding the thread you linked to, the person previously maintaining the userspace packages couldn't keep them up-to-date. The Arch devs don't maintain Arch for a living; their lives are no less complicated than the rest of ours. I'll gladly admit that the reason I'm all for eliminating these things is because I have no use for them myself, and removing them when I build my own kernel makes configuration slightly more inconvenient than it would be if they weren't there in the first place, and since no one seems to really use them regularly, there's no real sense in keeping them. But ultimately, if more people did use these things than didn't, and the devs deemed it worth their time to maintain them, then my own concerns are moot. They keep the OS I love stable and versatile; if deciding either keeping something I don't care for or eliminating something I find useful makes it easier for them to handle Arch development and maintainance, that counts for more than my convenience. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James <bigby.james@crepcran.com> wrote:
So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that "one day" is a year from now? Two years? And what if your time spent "experimenting" leads you to conclude that these things are "factually useless" to you? What then of the effort the devs put into it?
How did it happen that we're arguing about someone else's effort? Both of us are not trying to tell anyone to do anything, because people know that if they do something they do something and if they don't they don't. Stop standing in the way. cheers! mar77i
Am 28.03.2014 17:11, schrieb Martti Kühne:
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James <bigby.james@crepcran.com> wrote:
So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that "one day" is a year from now? Two years? And what if your time spent "experimenting" leads you to conclude that these things are "factually useless" to you? What then of the effort the devs put into it?
How did it happen that we're arguing about someone else's effort? Both of us are not trying to tell anyone to do anything, because people know that if they do something they do something and if they don't they don't. Stop standing in the way.
You can actually stop arguing about the SELinux issue entirely, since I think I heard all the basic arguments on both sides (if you have something _really_ new to add though, feel free to do so). I'll make up my mind about it and decide how we proceed.
I'll answer random things I read in the thread. First, I don't think the "lightweight" part of the philosophy is about using stock packages, as that's implied in the KISS philosophy, you don't need to stress it any more than that. The same KISS philosophy says one should try to avoid complexity whenever possible. Lastly, any decision taken will hurt someone. You keep the features? Then the ones who want the lighter, simpler kernel will suffer from a less tested build. You drop them? Servers (and any other user, whatever reason) will suffer from the same. However, the code paths they use exclusively are really not tested more by being in the main repos. Why? Because the ones using it, use it through AUR packages. If the feature is unusable without AUR packages, then they effectively get testing only from the ones who install AUR packages. Sure, they have some extra guarantee that drivers are not broken (except if they behave differently under AppArmor, SELinux, etc, do they?), but they don't have any testing on the actual features that are being included only because they use them. Needless to say, I'm all in favor of using minimal builds by default.
On 28-03-2014 10:54, Arthur Țițeică wrote:
It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled.
People in this thread like to put out the over subjective "lightweight" factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back.
Of the people that have pkgstats installed, almost no one is using any of the security features, selinux and apparmor don't even register in the stats [1], if they are not being used I don't see how removing/disabling them makes for a less secure system. Using selinux/apparmor/tomoyo requires comprehensive well written rules, which no one is willing to maintain because it is a huge and hard job. Things will subtly break after a while if rules are not rechecked with every package update, it's not a matter of if but when will they break, specially with arch that keeps close to the latest upstream releases. People have complained that audit pollutes their logs and apparently it is broken for containers and has to be disabled it with audit=0. Less code means less bugs and a smaller attack surface, and I suppose less of a burden for the one(s) actually maintaining the kernel package. If no one comes forward and says: please don't remove features a b and c because I'm actually making use of them in a production system, then I suppose the features will be removed. [1] https://www.archlinux.de/?page=PackageStatistics -- Mauro Santos
On 28/03/14 06:54 AM, Arthur Țițeică wrote:
Hi,
În ziua de Joi 27 Martie 2014, la 23:49:45, Thomas Bächler a scris:
And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line.
I couldn't find a definitive answer but the two documents I did find ¹² suggest that having selinux and audit fully functional (not just enabled) has no real performance impact.
Kernel debugging options on the other side seem to have a much bigger impact.
It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled.
These 'security measures' do nothing but provide hooks for malware to latch onto. Audit and LSM are a rootkit author's wet dream. It's strictly a security *improvement* to have them disabled if there's no userspace support as it just increases the kernel surface area and provides more useful post-exploitation tools. Claiming that we will have 'security measures disabled' is just hyperbole when Arch Linux is shipping with protected symlinks, hardlinks, ptrace_scope=1 and stack smashing protection. It certainly doesn't disable namespaces and seccomp-bpf.
People in this thread like to put out the over subjective "lightweight" factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back.
Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it. It's the same kind of hogwash as Windows security tokens, where it looks great from a theoretical point of view but is far too complex to actually use correctly. The Chromium sandbox is broken over and over on Windows because this complex token design simply doesn't work. On Linux, it uses a simple chroot, namespaces and seccomp whitelist. It doesn't ever get in the way of users, and it's easy for any developer to understand. If a story ran on the Guardian tomorrow showing that the NSA open-sourced SELinux to set back the development of MAC by *years* by sending people down the wrong path, I would not be the least bit surprised. :P
The facts will remain though:
* the kernel will still be "everything and the kitchen sink". * no provable performance enhancement so far. * security measures will get back at square 1.
Neither AppArmor or SELinux is provided in the official repositories, so enabling these in the kernel only adds attack surface. I doubt that using AUR packages provided by a different group of maintainers every week is going to improve anyone's security. If someone wants to attack Arch users, their easiest shot at it is taking over a somewhat popular AUR package (like apparmor) and sticking some subtly malicious code in the source or install file.
On 03/28/2014 09:12 AM, Daniel Micay wrote:
...
Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it.
I think the above is a tad misleading. While we don't yet have user space tools - which was I believe a key, if not critical, point Thomas was making - selinux is very useful and adds a strong security layer. The kernel code is well audited and well tested in real world too. Just not by us Arch folks - at least today - without the user space and policy support in core. I cannot speak for AppArmor, but I do recall when the big debate to include it in mainline or not was going on, that Linus was a big proponent of using both together. Hence, today both are there. And, it's not only for servers but for laptops as well. In fact newer versions of Android phones/tablets use selinux enabled in enforcing mode. So with the right user space policies (redhat has some good base configs here) selinux could be a strong add for Arch linux in the future - maybe. The discussion here, I thought, was whether having it in the stock Arch kernel offers any value to the community today. As Thomas said - it's pretty easy to build a custom kernel via abs if you want to work on user space policy etc. I would actually like to see Arch have selinux support - it would make us stronger - but we just don't have the tools and policies today. gene
On 28/03/14 02:36 PM, Genes Lists wrote:
On 03/28/2014 09:12 AM, Daniel Micay wrote:
...
Security needs to be simple, predictable and well understood. It needs to be provably correct and easily audited. SELinux is none of these things. I don't really understand why a distribution striving for simplicity would ever enable it.
I think the above is a tad misleading.
While we don't yet have user space tools - which was I believe a key, if not critical, point Thomas was making - selinux is very useful and adds a strong security layer. The kernel code is well audited and well tested in real world too. Just not by us Arch folks - at least today - without the user space and policy support in core.
Well I don't really think it's useful, There are much simpler alternatives, like isolating services and applications in containers (chroot, namespaces, seccomp-bpf) and using AppArmor + the protected symlink/hardlink switches (on by default) to pick up the slack when you're not willing to put in much work. Simplicity is really important in this domain, because you need to be able to audit a full policy, and that's very difficult when data is spread out through the filesystem. A mistake in the metadata for a single file can break the isolation. I don't really believe SELinux has a purpose beyond satisfying overly complex security policies created by bureaucracy. I can't see Arch ever being used in these situations.
I cannot speak for AppArmor, but I do recall when the big debate to include it in mainline or not was going on, that Linus was a big proponent of using both together. Hence, today both are there.
AppArmor was not incredibly useful before Yama came along with the protected symlink/hardlink features (now part of the core kernel). It's useful now, but I still think you're better off using containers in most cases. As far as I know, Linus is no fan of LSM and has done everything he can to keep this stuff out of the core kernel. There are cases where I think this was a mistake, like the `ptrace_scope` option requiring the stub Yama LSM.
And, it's not only for servers but for laptops as well. In fact newer versions of Android phones/tablets use selinux enabled in enforcing mode. So with the right user space policies (redhat has some good base configs here) selinux could be a strong add for Arch linux in the future - maybe.
Android is not exactly a shining example of a security. SELinux hasn't really changed anything other than adding a buzzword. The shared sdcard data can still be read/written by any application (no permissions or attributes there at all), and nothing else really changed. It might add some defence in depth, but they could have gotten this by leveraging namespaces/chroots or AppArmor too.
On Fri, Mar 28, 2014 at 12:54:44PM +0200, Arthur Țițeică wrote:
It raises a question mark that the two most important components of a system (systemd and the kernel) have security measures disabled.
People in this thread like to put out the over subjective "lightweight" factor but still there are no bug reports or any other solid evidence that the kernel ate their computers since apparmor, selinux and audit were semi-silently enabled a few builds back.
The facts will remain though:
* the kernel will still be "everything and the kitchen sink". * no provable performance enhancement so far. * security measures will get back at square 1.
There seems to be a general, significant misunderstanding floating around this thread. The "security features" in question are not passive; their mere existence within the binary kernel does not improve security. They are modules that allow users to fine-tune certain security features through the kernel using third-party tools, features that are almost exclusively useful for server administration (since, if you're the only one with access to your single-user machine, they won't tell you anything you can't already see without them). If you've never installed and configured the SELinux/AppArmor/Tomoyo userspace packages, you've never had the security they purport to provide. Hence the point of removing their modules from the kernel isn't performance; it's that *no one uses them,* and they clutter up the kernel configuration for no good reason at all, making it more tedious to maintain and just a bit more annoying to configure for individual users for absolutely no benefit. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
Hi, În ziua de Vineri 28 Martie 2014, la 12:54:44, Arthur Țițeică a scris:
As a side note I will try to test the worst case scenario in the Phoronix tests -- Postmark, and post the results here.
I managed to finish testing. As said above I picked up this test because it was the only one standing out with a great difference between the stock kernel and a selinux/audit configured kernel. It's also a very easy test to perform. The raw spreadsheet data and the conditions for the test may be found at ¹. I would really appreciate some help creating some nice graphs with this data. My conclusions so far: there's no difference between the stock -ARCH kernel and my -NOLSM build in which I disabled all LSMs (and hence audit). Note: the final test with 500000 files for the rotational disk isn't finished yet because... really... I shaved twice during the HDD tests. A side note regarding these tests: SSDs act according to their fame and HDDs are as misleading as a daily horoscope. I do plan to also test a no-debug but LSM enabled kernel even if it's just for the sake of statistics. ¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods -- Arthur Țițeică
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/2014 04:00 PM, Arthur Țițeică wrote:
My conclusions so far: there's no difference between the stock -ARCH kernel and my -NOLSM build in which I disabled all LSMs (and hence audit).
Note: the final test with 500000 files for the rotational disk isn't finished yet because... really... I shaved twice during the HDD tests.
A side note regarding these tests: SSDs act according to their fame and HDDs are as misleading as a daily horoscope.
I do plan to also test a no-debug but LSM enabled kernel even if it's just for the sake of statistics.
¹ https://dl.dropboxusercontent.com/u/29107946/linux-lsm/postmark-test.ods
Arthur, Thank you for taking the time to do these tests. At least this provides a bit of real-world performance data to consider. Please provide a link to the no-debug LSM enabled kernel data when you have shaved twice-more. I'll see if I can make a graph or two from the postmark-test.ods file. (my arts & crafts skills are a bit rusty, so no promises) - -- David C. Rankin, J.D.,P.E. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM8gc8ACgkQZMpuZ8CyrciWAgCePOf/0hN74giwdRUCpsHbUD5T 3iwAniygx5ouCZbna7VwpZMCaXbcPZKs =3mLX -----END PGP SIGNATURE-----
On Thu, Mar 27, 2014 at 5:46 AM, Thomas Bächler
The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core.
I was under the impression that this was s security feature to make it a bit more difficult to switch off your configured LSM. -- Pete
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel.
As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to "*I* use it, so don't take it away from me." But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use. When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease "testing" is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it?
That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways :
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config.
I've used Arch for years now, but I can remember what it was like as a n00b.
From the perspective of someone who is new to Arch, this is grossly misleading. Someone unfamiliar with how Arch packaging works (or a long-term Archer who doesn't pay close enough attention to the news and mailing lists) will conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and "linux-src" = "I have to screw with it for two hours to get my GPU working." They'll likely just install linux-full anyway, unaware of the distinction.
It seems far more reasonable to me to trim the kernel to those things typical of everyday desktop use, and trust that members of the community will maintain those things which they find useful separately. I don't mean to be presumptuous, but it's my understanding that the primary goal of the Arch devs and repo maintainers is to provide a minimal, functional distribution platform that users can utilize to craft their systems as they see fit. They don't want to cover every imaginable use-case, but provide users with tools with which to fulfill their own desires and needs themselves. What the devs provide in the base group, the [core] and [extra] repos are those things most common for mundane computer use via Linux-based operating systems. Special use cases are precisely what ABS and the AUR are there for. Requiring people to build a custom kernel in order to *not have these features* is the exact situation are already in *right now.* Asking the devs to maintain multiple kernels just to save what I suspect is a minority---who already build several packages from the AUR, for rarely used functionality---a little time isn't reasonable. Moreover, while I may mistake your meaning, the list above reads like you're asking the developers to make your preferred kernel build the default, and reasoning that "It's no big deal, if people don't want that stuff they can just build their own through ABS." That's not a solution at all, and again, *it's already the case right now.* -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
2014-03-27 16:31 GMT+01:00 Bigby James <bigby.james@crepcran.com>:
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel.
As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to "*I* use it, so don't take it away from me." But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use.
When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease "testing" is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it?
Sorry if my message sounded too much as "I use it so I want other people to make my life easier". That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg00009.html). Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of "normal" people by replacing "SELinux" with "Linux containers", which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody noticing?).
That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways :
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config.
I've used Arch for years now, but I can remember what it was like as a n00b. From the perspective of someone who is new to Arch, this is grossly misleading. Someone unfamiliar with how Arch packaging works (or a long-term Archer who doesn't pay close enough attention to the news and mailing lists) will conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and "linux-src" = "I have to screw with it for two hours to get my GPU working." They'll likely just install linux-full anyway, unaware of the distinction.
It seems far more reasonable to me to trim the kernel to those things typical of everyday desktop use, and trust that members of the community will maintain those things which they find useful separately. I don't mean to be presumptuous, but it's my understanding that the primary goal of the Arch devs and repo maintainers is to provide a minimal, functional distribution platform that users can utilize to craft their systems as they see fit. They don't want to cover every imaginable use-case, but provide users with tools with which to fulfill their own desires and needs themselves. What the devs provide in the base group, the [core] and [extra] repos are those things most common for mundane computer use via Linux-based operating systems. Special use cases are precisely what ABS and the AUR are there for.
Requiring people to build a custom kernel in order to *not have these features* is the exact situation are already in *right now.* Asking the devs to maintain multiple kernels just to save what I suspect is a minority---who already build several packages from the AUR, for rarely used functionality---a little time isn't reasonable. Moreover, while I may mistake your meaning, the list above reads like you're asking the developers to make your preferred kernel build the default, and reasoning that "It's no big deal, if people don't want that stuff they can just build their own through ABS." That's not a solution at all, and again, *it's already the case right now.*
Ok, my wording had been really bad if people understood that :( What I'm trying to do is to make things easier for other people, not myself (whatever the final decision is, I'll still use Arch in a config which is not the default), and I certainly don't want the devs to waste time doing duplicated work. The ideas of having multiple supported kernel was a bad one (and thanks for pointing that out) but I needed to ask what I asked to understand better (and to make people with similar questions as I understand better) why this thread is about "shrinking the supported kernel configuration" and not about "creating a new smaller kernel". My post was also to start thinking of what I will answer to people in a few months when they'll ask "why do I need to recompile my kernel to use SELinux? I don't have to recompile sudo to have OpenLDAP support?" (these are quite random package names). I'll answer these people that the kernel is not a package like others and that most people want a kernel as small as possible, but don't care about feature-complete packages. Thanks, Nicolas
I am a complete noob and only follow the lists out of interest. I am also very young, so please forgive my impertinence. Thanks Thomas for your work!! Just my 2c: On 03/27/2014 08:34 PM, Nicolas Iooss wrote:
2014-03-27 16:31 GMT+01:00 Bigby James <bigby.james@crepcran.com>:
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel.
As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to "*I* use it, so don't take it away from me." But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use.
When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease "testing" is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it?
Sorry if my message sounded too much as "I use it so I want other people to make my life easier". That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg00009.html).
Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of "normal" people by replacing "SELinux" with "Linux containers", which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody noticing?).
That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways :
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config.
I've used Arch for years now, but I can remember what it was like as a n00b. From the perspective of someone who is new to Arch, this is grossly misleading. Someone unfamiliar with how Arch packaging works (or a long-term Archer who doesn't pay close enough attention to the news and mailing lists) will conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and "linux-src" = "I have to screw with it for two hours to get my GPU working." They'll likely just install linux-full anyway, unaware of the distinction.
It seems far more reasonable to me to trim the kernel to those things typical of everyday desktop use, and trust that members of the community will maintain those things which they find useful separately. I don't mean to be presumptuous, but it's my understanding that the primary goal of the Arch devs and repo maintainers is to provide a minimal, functional distribution platform that users can utilize to craft their systems as they see fit. They don't want to cover every imaginable use-case, but provide users with tools with which to fulfill their own desires and needs themselves. What the devs provide in the base group, the [core] and [extra] repos are those things most common for mundane computer use via Linux-based operating systems. Special use cases are precisely what ABS and the AUR are there for.
Requiring people to build a custom kernel in order to *not have these features* is the exact situation are already in *right now.* Asking the devs to maintain multiple kernels just to save what I suspect is a minority---who already build several packages from the AUR, for rarely used functionality---a little time isn't reasonable. Moreover, while I may mistake your meaning, the list above reads like you're asking the developers to make your preferred kernel build the default, and reasoning that "It's no big deal, if people don't want that stuff they can just build their own through ABS." That's not a solution at all, and again, *it's already the case right now.*
Ok, my wording had been really bad if people understood that :( What I'm trying to do is to make things easier for other people, not myself (whatever the final decision is, I'll still use Arch in a config which is not the default), and I certainly don't want the devs to waste time doing duplicated work.
The ideas of having multiple supported kernel was a bad one (and thanks for pointing that out) but I needed to ask what I asked to understand better (and to make people with similar questions as I understand better) why this thread is about "shrinking the supported kernel configuration" and not about "creating a new smaller kernel".
Because of this: "Arch Linux defines simplicity as without unnecessary additions, modifications, or complications, and provides a lightweight UNIX-like base structure that allows an individual user to shape the system according to their own needs. In short: an elegant, minimalist approach."[1] The main kernel *should* be simple *_by that definition_*. From my (limited) point of view, the default in Arch should always be the most lightweight, practical solution. This is not RHEL or Ubuntu, we have a very limited workforce and want to be simple. I hope that I didn't offend anybody.
My post was also to start thinking of what I will answer to people in a few months when they'll ask "why do I need to recompile my kernel to use SELinux? I don't have to recompile sudo to have OpenLDAP support?" (these are quite random package names). I'll answer these people that the kernel is not a package like others and that most people want a kernel as small as possible, but don't care about feature-complete packages.
Thanks,
Nicolas
Cheers, Bennett [1]source: https://wiki.archlinux.org/index.php/The_Arch_Way
On 27.03.2014 21:59, Bennett Piater wrote:
I am a complete noob and only follow the lists out of interest.
First lesson which also applies to a bunch of other people in this thread: only quote what you need. 129 lines of quoted text before your reply is bad.
On 03/27/2014 10:06 PM, Florian Pritz wrote:
On 27.03.2014 21:59, Bennett Piater wrote: First lesson which also applies to a bunch of other people in this thread: only quote what you need. 129 lines of quoted text before your reply is bad.
Thanks for the tip, I'll remember it. :)
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
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
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.
My opinion on this is that the kernel should be the ground on which userspace should always work. Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks. Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this. Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel. If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 10000 I personally don't see it as good bargain. Building a personal or an AUR linux package is easy. Maintaining one is a lot harder. The most important thing that is lost in this process is the community support. One cannot compare the scrutiny and the testing of any AUR linux package with those of the -ARCH kernel. That being said I'd like to read and help test a before and after kernel in regards to performance or any other concerning factor. -- Arthur Țițeică
My opinion on this is that the kernel should be the ground on which userspace should always work.
Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks.
Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this.
Specifically regarding slowdowns, my layman opinion on this is that
On Thursday, March 27, 2014 04:45:24 PM Arthur Țițeică wrote: they are
meaningless in the general usage of the -ARCH kernel.
If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 10000 I personally don't see it as good bargain.
This seems like it doesn't exactly fit with the Arch Way though. Arch is supposed to be simple and minimal. Why should the default be "add all the features" for a distribution that is partially based on being minimal and lightweight? I guess I just don't see the reason for adding in feature by default that so few people will actually use. And the people who will be using it should have the knowledge and ability to build their own kernel that will have those features enabled.
On Thu, Mar 27, 2014 at 10:11 AM, Kevin Ott
This seems like it doesn't exactly fit with the Arch Way though. Arch is supposed to be simple and minimal. Why should the default be "add all the features" for a distribution that is partially based on being minimal and lightweight?
I guess I just don't see the reason for adding in feature by default that so few people will actually use. And the people who will be using it should have the knowledge and ability to build their own kernel that will have those features enabled.
I thought part of 'minimal' meant that the packages were as stock as possible. I was under the impression that we shipped minimally altered packages and it was up to the administrator to perfect each package to her liking. I thought we only make a few little patches to the default kernel in the repo and anyone who wants to strip drivers and use BFS is welcome to do so through the AUR and/or ABS. I don't really use stock kernel so it doesn't matter to me, but for point of reference, (and please correct me if I'm wrong here) I thought default in the repos was the generally accepted Arch Way. -- Pete
On Thu, Mar 27, 2014 at 2:19 PM, Peter Baldridge <petebaldridge@gmail.com> wrote:
I thought part of 'minimal' meant that the packages were as stock as possible. I was under the impression that we shipped minimally altered packages and it was up to the administrator to perfect each package to her liking.
The kernel doesn't need to be patched to remove any of this functionality. It's all done though the kernel configuration file which isn't supplied upstream. Joel
On Thursday, March 27, 2014 02:19:28 PM Peter Baldridge wrote:
I thought part of 'minimal' meant that the packages were as stock as possible. I was under the impression that we shipped minimally altered packages and it was up to the administrator to perfect each package to her liking.
I thought we only make a few little patches to the default kernel in the repo and anyone who wants to strip drivers and use BFS is welcome to do so through the AUR and/or ABS.
I don't really use stock kernel so it doesn't matter to me, but for point of reference, (and please correct me if I'm wrong here) I thought default in the repos was the generally accepted Arch Way.
I'm pretty sure your summary is accurate. However, these are things done in a configuration file when building the kernel. There isn't really a "default". So the question then becomes: Should the default build for the kernel contain "everything and the kitchensink [sic]"?
On 27 March 2014 21:34, Kevin Ott <supercodingmonkey@gmail.com> wrote:
I'm pretty sure your summary is accurate. However, these are things done in a configuration file when building the kernel. There isn't really a "default".
There is -- download the kernel sources and run "make defconfig". It'll start with the current default for the architecture you're building on [1 - x86_64][1 - i386], (which might not be up-to-date), then sets any new flags to their default state. I dunno how usable the default config is though, presumably not very, or else Arch wouldn't deviate so from the defaults so much as to need to ship custom configs with ABS. WorMzy [1 - x86_64] https://github.com/torvalds/linux/blob/master/arch/x86/configs/x86_64_defcon... [1 - i386] https://github.com/torvalds/linux/blob/master/arch/x86/configs/i386_defconfi...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2014 09:45 AM, Arthur Țițeică wrote:
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
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.
My opinion on this is that the kernel should be the ground on which userspace should always work.
Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks.
Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this.
Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel.
If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 10000 I personally don't see it as good bargain.
Building a personal or an AUR linux package is easy. Maintaining one is a lot harder. The most important thing that is lost in this process is the community support. One cannot compare the scrutiny and the testing of any AUR linux package with those of the -ARCH kernel.
That being said I'd like to read and help test a before and after kernel in regards to performance or any other concerning factor.
First, +1 for the response. Second, after reading this entire thread, I think it comes down to this: If maintaining the current config with SELinux, SMACK, etc.. support is a significant part of maintaining the kernel package for TB, then that is the argument for ditching it. If you are spending 30% of kernel package maintenance time of this stuff for the benefit of a few users, then it makes sense to drop it and let whoever uses it maintain that config, and possibly add an EXTRA/AUR linux-SELinux-kernel-config.tar.xz package (and -SMACK, -LSM) to make that config available so that every user who wants to build the kernel with that support does not have to reinvent the wheel for each rebuild. I do not know what level of effort is involved in maintaining that config, but if doing so requires significant effort, that effort should be borne by those making use of it and not TB. If removal is needed due to claimed performance issues, then it takes test-case evidence to support that. Otherwise, the reasoning is no better than search location for MH370. I support TB's effort to trim down the config, but if providing the current options is no-cost from a maintenance, security or performance standpoint, then there is no reason not to provide the capability in the kernel. I think this discussion is well worth the effort to identify what in the current config has a cost (in maintenance, security or performance) that outweighs the benefit the feature provides. Those are the parts of the config that should be trimmed and moved to user-maintenance. - -- David C. Rankin, J.D.,P.E. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM8h3gACgkQZMpuZ8CyrcjpLwCeNR/NE6ya1KekdtzdgaiCRJY6 BoEAn23SlMmF6DiicHjTlK/h50ApV5WV =aHYI -----END PGP SIGNATURE-----
The audit support required by these can't be compiled in without it being enabled. It's useless crap for anyone who isn't working for a bureaucracy and it spams the logs. It is also completely broken with namespaces, so it doesn't work at all with containers or application sandboxes. If and when this stuff can be built as *modules* with no impact on people not making use of it and someone is willing to maintain the userspace support in the official repositories, then enabling it may make sense. Until then, you can use any sane LSM module without recompiling the kernel by building just the module you plan on using and loading it.
În ziua de Mie 02 Apr 2014, la 18:50:14, Daniel Micay a scris:
Until then, you can use any sane LSM module without recompiling the kernel by building just the module you plan on using and loading it.
I'm no kernel hacker by any means but AFAIK the LSM framework is still there with CONFIG_SECURITY, it's just the modules that are missing. In the end the trimming guys gain nothing because the the security "bloat" (the LSM framework) is still in the kernel and the security guys lost the modules. Did I get anything wrong? -- Arthur Țițeică
On 03/04/14 06:41 PM, Arthur Țițeică wrote:
În ziua de Mie 02 Apr 2014, la 18:50:14, Daniel Micay a scris:
Until then, you can use any sane LSM module without recompiling the kernel by building just the module you plan on using and loading it.
I'm no kernel hacker by any means but AFAIK the LSM framework is still there with CONFIG_SECURITY, it's just the modules that are missing.
The LSM support is still there due to Yama. It would be great if support for `ptrace_scope` was simply included in the core kernel. Since the `protected_symlinks` and `protected_hardlinks` switches landed, I think there's a good chance of something like this ending up there too.
In the end the trimming guys gain nothing because the the security "bloat" (the LSM framework) is still in the kernel and the security guys lost the modules. Did I get anything wrong?
Yes, you've got it wrong. The kernel logs are no longer being spammed by useless audit crap. As I said in the email you're replying to:
The audit support required by these can't be compiled in without it being enabled. It's useless crap for anyone who isn't working for a bureaucracy and it spams the logs. It is also completely broken with namespaces, so it doesn't work at all with containers or application sandboxes.
I don't think the 'security guys' lost much, considering that none of this worked without userspace support that we do not have. SELinux and Smack require the recompilation of userspace packages, including with patches for SELinux. AppArmor requires kernel patches missing in the mainline kernel to work correctly.
participants (20)
-
Arthur Țițeică
-
Bennett Piater
-
Bigby James
-
Daniel Micay
-
David C. Rankin
-
Florian Pritz
-
Genes Lists
-
Joel Teichroeb
-
Kevin Ott
-
Leonid Isaev
-
Mario Rugiero
-
Martti Kühne
-
Mauro Santos
-
Nicolas Iooss
-
Paul Gideon Dann
-
Peter Baldridge
-
Savyasachee Jha
-
Simon Brand
-
Thomas Bächler
-
WorMzy Tykashi