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

[Bartłomiej Piotrowski]

On Wed, 16 Apr 2014 00:09:55 -0400
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
> 
> 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.
> 

I'd really like to see it in our repositories, as long as it doesn't
require any additional actions from other maintainers. I used to
maintain my own PKGBUILD for quite a long time, but compiling whole
kernel for only one machine was a bit toilsome.

Could we add it to [community] at least experimentally and in case of
further concerns just remove it?

-- 
Bartłomiej Piotrowski
http://bpiotrowski.pl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140419/1cb6c952/attachment-0001.asc>