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

[Tom Gundersen]

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.

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?

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?

Cheers,

Tom

> The grsecurity project has been around since 2001 and has fundamentally
> different goals than the mainline Linux project. Much like OpenBSD, it
> makes changes with a measurable performance or compatibility impact that
> are unlikely to ever be included in the upstream kernel. Many of these
> changes involve hardening the kernel against userspace exploitation,
> which is not something tackled by any of the Linux Security Modules.
> Users, groups, ACLs, chroots and namespaces already provide a solid
> foundation for access control, so hardening the kernel itself is the
> single biggest security improvement involved.
>
> It has various odds and ends exposed via sysctl switches, and these tend
> to trickle upstream in one form or another (symlink/hardlink protection,
> dmesg restriction, /proc restrictions).
>
> It also includes the PaX project to provide a much stronger
> implementation of ASLR along with significant memory protections for
> userspace. These features do break many packages, and require setting
> flags on binaries when exceptions are necessary. I don't want to place a
> burden on other packagers, so I plan on leaving the parts requiring
> integration with other packages disabled at first.
>
> If there turns out to be more interest than just my own in maintaining
> this, flipping on the PaX protections by default and setting the
> required flags in various packages could be considered. I don't want to
> approach this by filing bugs, so there would need to be a developer
> interested in doing some work on packages in [core] and [extra] for
> these kinds of features to be enabled.
>
> SELinux requires many packages to be built with support for it, along
> with a significant number of patches. The policies are very complex and
> spread out through the entire file system. In my opinion, it's pretty
> much the antithesis of Arch's goals of simplicity and transparent
> configuration.
>
> AppArmor/TOMOYO are much simpler, with centralized policy files that are
> much easier to review or ship in packages. The grsecurity RBAC system is
> similar to these and has a nice automatic learning mode. However, it's
> quite a bit more powerful and grsecurity is useful even without
> providing RBAC policies since this is only one component.
>
> All in all, I think grsecurity would be a great way of improving the
> level of security we offer. It's also one of the least intrusive ways of
> doing it, since it can provide significant benefits without everyone
> buying into it and adding profiles to their packages. There will be no
> impact on the regular/default kernel, so it's far friendlier to users
> who don't care about this than SELinux/AppArmor/Audit.
>