On Wed, 16 Apr 2014 00:09:55 -0400 Daniel Micay <[email protected]> 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/
signature.asc
Description: PGP signature
