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.