[arch-dev-public] providing grsecurity in [community]

[Daniel Micay]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140418/1033f50f/attachment-0001.asc>