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

[Daniel Micay]

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


-------------- 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/20140418/7501c369/attachment.asc>