On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler 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

On Wed, 26 Mar 2014 22:17:25 +0100 Thomas Bächler wrote:

Am 26.03.2014 21:31, schrieb Leonid Isaev:

...

On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler 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

Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev :

On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler wrote:

...

Hello all,

it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone.

I want to trim our kernel down to what we actually support.

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

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

-----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-----

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 :

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

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 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 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

Am 28.03.2014 17:11, schrieb Martti Kühne:

On Fri, Mar 28, 2014 at 4:03 PM, Bigby James 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.

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 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 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

-----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 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

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 :

...

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 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 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 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]"?

-----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-----

Î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ă