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

[Daniel Micay]

On 18/04/14 05:11 PM, Tom Gundersen wrote:
> On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay at gmail.com> wrote:
>> There has been a recent surge of interest in securing Arch by paying
>> closer attention to CVEs and addressing many security issues in our
>> packages. I also started some initial work/documenting on securing the
>> services shipped in various packages:
>>
>> https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
> 
> I'm very happy that more people are now looking at security related
> things in Arch. Nice work!
> 
>> 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. This would be the first case of an
>> alternative kernel in the repositories, so I'm open to discussion about
>> whether it's appropriate to do this. There are also some issues relevant
>> to other packages in the repositories.
> 
> Hmm, grsec seems like a dead-end to me. It will never land upstream,
> and hence will never be in our standard kernel and our default
> packages will therefore never be integrated with it. So whatever work
> you do will have to live independently in perpetuity. At worst it
> would split our (very limited) development and QA resources.

There's nothing else hardening the kernel itself against exploitation,
so containers (namespaces, seccomp-bpf) aren't going to benefit from any
other work. I don't see much point in spending my time integrating an
LSM when they're just layering on more complexity without fixing the
lowest hanging fruit. The work that's done in grsecurity trickles into
the kernel years later, so it's not really a dead end.

I understand if touching any other packages is viewed as unacceptable
and can work around that issue. The RBAC policies will be entirely
centralized in the gradm package, and I can try to take the quirky
approach of doing all of the PaX exceptions there. No other packages
will be aware of anything going on, unless people feel like taking the
completely optional step of making DKMS versions of modules. The only
time spent on this is going to be my own.

I've already spent far more time writing these mailing list responses
than any amount of work I've put into improving security-related
issues... speaking of development resources.

> Would it not make more sense to focus on some other security features
> that are actually upstream and which can then at least potentially be
> merged into our default packages eventually?

We do have ptrace_scope, protected_symlinks and protected_hardlinks
enabled, which are bits of grsecurity that made it into the kernel after
many years. The upstream kernel only has ASLR at all because PaX
invented it in the early 2000s. We could enable dmesg_restrict /
kptr_restrict but there's not much value until KASLR can be turned on.
Even then, there's little value in KASLR (or ASLR) when many upstream
maintainers simply don't care about breaking it by leaking addresses.

Flipping on PIE for some executables would be an improvement, but it's a
lot more valuable with the improved PaX ASLR.

> Maybe another option, if you really think grsec is the way to go,
> would be to simply create a new unofficial repository and put the
> packages there instead?

I do really think it's the way to go. If it has to be walled off outside
of the repositories, there's a lot less value in it. I'm unlikely to
waste any more time trying to improve this aspect of the distribution if
it's just shot down.

To be perfectly honest, I didn't feel I had to ask for permission to
maintain a 13 year old open-source project with 43 votes in [community]
and had no idea there would be such a negative response.

We have plenty of forks like graphicsmagick and even two entire desktop
environments forked from GNOME (Mate and Cinnamon). There's at least one
proprietary driver that's never going to be open-source let alone
integrated upstream, and plenty of *truly* dead-end projects with no
upstream (metacity!).

-------------- 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/4f8d71f4/attachment.asc>