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

[Daniel Micay]

On 19/04/14 03:28 AM, Bartłomiej Piotrowski wrote:
> 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?

I don't really see any problem with moving a FOSS package with 52 votes
to [community]. Whether or not people like the project isn't really
relevant. The very real out-of-tree module issue has been tackled by
deciding on the use of DKMS.

I regret talking about PaX exceptions at all because I've realized it
can just be handled entirely within the package. I think mentioning that
threw off the whole conversation from the start, although I guess it was
worth it if Pacman learns about extended attributes :P.

If the package really does throw someone's cat in a blender, they're
free to remove it. It seems the only way to demonstrate it won't give
anyone any extra work to do is to just do it...

-------------- 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/20140420/f72d4f82/attachment-0001.asc>