Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
-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 50 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-
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
-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 1 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-
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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=articleitem=fedora_debug_selinux ² https://dl.dropboxusercontent.com/u/29107946/Assessing-the-Performance-Impact-of-the-Linux-Kernel-Audit-Trail.pdf 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ă signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 11:54 AM, Arthur Țițeică art...@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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 2:40 PM, Bigby James bigby.ja...@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.html
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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.html 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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 28.03.2014 17:11, schrieb Martti Kühne: On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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 50 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ă signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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.io...@m4x.orgwrote: Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@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 --
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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). signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
-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-
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Î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 1 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ă signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 22:17:25 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 21:31, schrieb Leonid Isaev: On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler tho...@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 signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thursday, March 27, 2014 04:45:24 PM Arthur Țițeică wrote: 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 1 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.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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 tho...@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/security.c?id=v3.13 and http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?id=v3.13#n5977 , 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_write.c#n367 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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@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/msg9.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'
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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.ja...@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/msg9.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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 2:19 PM, Peter Baldridge petebaldri...@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
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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/audit.c?id=v3.13#n1001). 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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 27 March 2014 21:34, Kevin Ott supercodingmon...@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_defconfig [1 - i386] https://github.com/torvalds/linux/blob/master/arch/x86/configs/i386_defconfig
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@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 signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler tho...@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 signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 26/03/14 02:56 PM, Thomas Bächler wrote: Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. I think we should drop x32 support if no one is planning on packaging the minimum of a compiler and standard C library. It's cool, but no one appears to be very interested in using it in the real world. You would probably get bigger wins from recompiling with -march=native, so I somewhat doubt that anyone grasping for the last bit of performance will use our binaries anyway. This was already responsible for a security vulnerability in Arch: http://seclists.org/oss-sec/2014/q1/187 signature.asc Description: OpenPGP digital signature
