2014-03-27 16:31 GMT+01:00 Bigby James <bigby.james@crepcran.com>:
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
Here are three arguments to motivate my disagreement.
* First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks "I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config". Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel.
As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to "*I* use it, so don't take it away from me." But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use.
When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease "testing" is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it?
Sorry if my message sounded too much as "I use it so I want other people to make my life easier". That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg00009.html). Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of "normal" people by replacing "SELinux" with "Linux containers", which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody noticing?).
That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways :
a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as "linux-full" (as an official package) and trim linux' config. c) Create a package ("linux-src"?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly).
Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config.
I've used Arch for years now, but I can remember what it was like as a n00b. From the perspective of someone who is new to Arch, this is grossly misleading. Someone unfamiliar with how Arch packaging works (or a long-term Archer who doesn't pay close enough attention to the news and mailing lists) will conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and "linux-src" = "I have to screw with it for two hours to get my GPU working." They'll likely just install linux-full anyway, unaware of the distinction.
It seems far more reasonable to me to trim the kernel to those things typical of everyday desktop use, and trust that members of the community will maintain those things which they find useful separately. I don't mean to be presumptuous, but it's my understanding that the primary goal of the Arch devs and repo maintainers is to provide a minimal, functional distribution platform that users can utilize to craft their systems as they see fit. They don't want to cover every imaginable use-case, but provide users with tools with which to fulfill their own desires and needs themselves. What the devs provide in the base group, the [core] and [extra] repos are those things most common for mundane computer use via Linux-based operating systems. Special use cases are precisely what ABS and the AUR are there for.
Requiring people to build a custom kernel in order to *not have these features* is the exact situation are already in *right now.* Asking the devs to maintain multiple kernels just to save what I suspect is a minority---who already build several packages from the AUR, for rarely used functionality---a little time isn't reasonable. Moreover, while I may mistake your meaning, the list above reads like you're asking the developers to make your preferred kernel build the default, and reasoning that "It's no big deal, if people don't want that stuff they can just build their own through ABS." That's not a solution at all, and again, *it's already the case right now.*
Ok, my wording had been really bad if people understood that :( What I'm trying to do is to make things easier for other people, not myself (whatever the final decision is, I'll still use Arch in a config which is not the default), and I certainly don't want the devs to waste time doing duplicated work. The ideas of having multiple supported kernel was a bad one (and thanks for pointing that out) but I needed to ask what I asked to understand better (and to make people with similar questions as I understand better) why this thread is about "shrinking the supported kernel configuration" and not about "creating a new smaller kernel". My post was also to start thinking of what I will answer to people in a few months when they'll ask "why do I need to recompile my kernel to use SELinux? I don't have to recompile sudo to have OpenLDAP support?" (these are quite random package names). I'll answer these people that the kernel is not a package like others and that most people want a kernel as small as possible, but don't care about feature-complete packages. Thanks, Nicolas