On 18/04/14 04:29 AM, henning mueller wrote:
Hey,
I'm replying to a thread on arch-dev-public with the same subject, here.
I'm maintaining the linux-grsec PKGBUILD in the AUR [0], wrote an utility to set PaX flags [1] and host a repository for binary grsecurity packages [2]. Although I like the idea of further integrating grsecurity into Arch Linux, I have some points to criticize on the planning proposals of Daniel Micay.
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.
1. The very core of the grsecurity project is PaX. Without it, you miss out on the most effective security features. Some contributing linux-grsec users and me collected numerous binaries, which do not work well with PaX and the according PaX features, which have to be disabled in order to get them running. These are currently collected in the linux-pax-flags utility [1]. For a clean grsecurity integration, any flags on [core], [extra] and [community] should be set before releasing linux-grsec in [community].
By leaving it disabled, I mean enabling the soft mode compilation option and having it disabled out-of-the-box. The PaX features will still be compiled in to the kernel. A user will still be able to install the linux-pax-flags package from the AUR and disable soft mode via the sysctl flag. As far as I can tell, it's also possible to deal with PaX exceptions entirely via an RBAC profile, so shipping a default-enabled RBAC profile would be an alternative. Even with PaX in soft mode, grsecurity comes with a significant amount of kernel hardening, miscellaneous features (like auditing), and of course the RBAC implementation which fills the gap left by the removal of AppArmor/TOMOYO support from the [core] kernel. In my opinion, the RBAC support is the most significant feature in the context of Arch Linux, where no other MAC solution has caught on. I don't think SELinux is a good fit due to the complexity, opaque configuration and necessary patches. The path-based policy files used in AppArmor/TOMOYO are great, but RBAC provides more flexibility and resolving the paths to inodes before enforcement prevents the link-based issues.
It would have no impact on people not using it, since it would just be a very short string set in the `user.pax.flags` xattr key. For example, `setfattr -n user.pax.flags -v "mr" "$pkgdir/usr/bin/foo"` to disable MPROTECT and RANDMMAP features (on chromium, firefox, etc.).
2. I think, manually setting the flags with a setfattr call in the PKGBUILDs is a bad solution, because it is error-prone. The Gentoo (hardened) folks integrated a new function for marking binaries with PaX flags into the ebuild environment. I would prefer a solution like this for Arch, too. A new PKGBUILD variable for PaX flags to be set after install() would also be a good solution (like PAX_FLAGS=(usr/bin/firefox:mr). (There is also a utility which supports xattr flags by the Gentoo hardened folks named paxctl-ng.)
I don't think there's an advantage to using install scripts rather than the PKGBUILD itself. Pacman can learn to preserve extended attributes, and it's much cleaner for this to be a tracked attribute of the package rather than an ad-hoc hack. Realistically, grsecurity is going to need a significant userbase (via pkgstats) before a convincing argument can be made that this is something Arch's packages should support. I don't think an AUR package with 43 votes is anywhere close to enough proof that this is actually going to see widespread usage. Moving it to the repositories and providing a good out-of-the-box experience is what needs to happen for this to gain the critical mass of users (including other developers / trusted users) required to really integrate it with the distribution. I think the linux-pax-flags package can fill the gap until there's either enough interest to maintain the flags across many packages, or another solution like using RBAC is put in place.
3. I do not know, what the policy is, here, but I would prefer to maintain the PKGBUILD myself, if it gets included in [community]. At least, I would have expected to be integrated in the discussion a little more. I did the work on it since beginning of 2012 and run it on several machines since then. I think, a message like "I will adopt your package in [community]" is a little rude. The gradm package was already deleted from the AUR. On the linux-pax-flags AUR package, Daniel commented that I would have to change it to work according to his plans.
I'm aware that you've spent a long time maintaining the package, and I'm thankful for the hard work you've put into it. However, I have a different view on how the packaging should be done. I want switching from the linux package to linux-grsec to be a painless experience without any breakage. After booting into a working grsecurity environment, users can tighten up the sysctl knobs to their liking and begin setting grsec_lock=1 if they desire. At the moment, booting into the grsecurity kernel starts off users in an environment where many things like containers, profiling (perf), network bandwidth displays, etc. no longer work. I realize that starting from everything forbidden and building a whitelist is a nice ideal, but booting into an install where the web browser can't be started and many of your services fail to start is enough to drive most users away from exploring further.
I want to mention another step, that would be necessary for a decent integration of grsecurity and full ASLR: The activation of PIE/PIC. This has been discussed a little on the Arch Linux BBS [3]. Allan stated that "If there is a good way to add it for x86_64, it will be considered." Maybe it is possible to come up with a good way.
There are a important few packages already using PIE like Chromium and OpenSSH, although this is likely because the projects are security-focused and set this in their build system.
Best regards, henning
[0] https://aur.archlinux.org/packages/linux-grsec [1] https://github.com/nning/linux-pax-flags [2] https://arsch.orgizm.net [3] https://bbs.archlinux.org/viewtopic.php?id=172955