On 18/04/14 05:09 AM, Gaetan Bisson wrote:
[2014-04-16 00:09:55 -0400] Daniel Micay:
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.
It sounds fairly intrusive to me to introduce and support a new kernel in our repositories.
I don't expect anyone but myself to put any work into supporting it. A few other developers and trusted users may be interested in helping, but I can certainly take care of it myself if there isn't interest. It's far less invasive than asking for features like SELinux to be enabled in all of our packages. I think most people who would be asking for the [core] kernel to support TOMOYO/AppArmor/SELinux/Smack/Audit will be more than happy to use grsecurity instead.
And I feel quite uneasy about this set of patches not having been accepted upstream.
It makes changes like adding (mostly) redundant checks to reference counting and bounds checks on copies to/from userspace with a measurable performance cost. These changes prevent many of the discovered kernel vulnerabilities from working on a grsecurity kernel. These features don't prevent bugs, but rather stop them from becoming exploitable vulnerabilities. Linus doesn't see security issues as meriting special treatment over other bugs, and trying to sell a 1-5% performance loss upstream is just not going to happen. ASLR was invented by the PaX team, along with other mitigation techniques that are now upstream. Many of the non-PaX grsecurity features have also made their way into the Linux kernel (ptrace_scope, hidepid, fs.protected_symlinks, fs.protected_hardlinks, dmesg_restrict, kptr_restrict, etc.) and other operating systems. The mainline kernel still hasn't caught up to where it was ten years ago, and there has been a significant amount of new research and feature development since then.
Is there a particular reason why the current state (packages in the AUR, built on-demand by those users that are interested) is dissatisfying?
You might as well ask why I want to maintain any packages at all. :P I think I can offer a good out-of-the-box experience with this package in the repositories. The userspace support is relevant whether someone uses a grsecurity package from the repositories or builds their own.
In your view, should we also package other patchsets, such as Con Kolivas' (by far the most popular linux-* package on the AUR)?
I'm fine with other people packaging any FOSS under the sun if it has an active upstream and isn't going to put a burden on other developers / trusted users. I don't think we should bring more dead projects or proprietary software into the repositories but this is neither. I'm not familiar with what the CK patches do, so I can't really voice an opinion on whether they are worth including in the repositories. I don't think votes are a good measure of interest in a package, since it's tied to age and automatic voting by some AUR helpers. For all we know, someone used a script to create a bunch of accounts to vote for it. If someone writes an explanation of what it is and why it would be valuable to include in the repositories then I can give an answer.