On 19/04/14 03:28 AM, Bartłomiej Piotrowski wrote: > On Wed, 16 Apr 2014 00:09:55 -0400 > Daniel Micay <danielmi...@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...
signature.asc
Description: OpenPGP digital signature