Re: [arch-dev-public] providing grsecurity in [community]
On 18/04/14 04:29 AM, henning mueller wrote:
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.
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.
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.
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.
participants (1)
-
Daniel Micay