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

[Daniel Micay]

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

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.

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.

-------------- 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/20140416/c51491f9/attachment.asc>