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

[Daniel Micay]

On 19/04/14 05:25 PM, Tom Gundersen wrote:
> On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay <danielmicay at gmail.com> wrote:
>> Users have been asking for MAC to be provided in the repositories for a
>> long time. At the moment, two bugs are open about it:
>>
>> https://bugs.archlinux.org/task/37578
>> https://bugs.archlinux.org/task/39852
>>
>> Any of these reported bugs could simply be closed with the response that
>> the grsecurity RBAC is provided in the repositories and there's  no one
>> interested in maintaining another. I think that's a response most people
>> would be satisfied with, but users aren't going to be very happy with an
>> a WONTFIX simply saying Arch has no official support for any of this.
> 
> I would see this the other way around (which is one of the reasons I
> don't think adding forks of the kernel is such a great idea). It would
> be very nice if we could manage to support some more security features
> in the main kernel, but asking people to use an alternative kernel if
> they want security features seems wrong. Especially if it is used as
> an excuse not to get things that are already upstream working with the
> main kernel we provide.

These features aren't in the regular kernel though. There's no way to
have anything but the weak ASLR implementation with missing pieces. It
has no configuration option to flip on similar hardening options. All of
the MAC implementations in the kernel are limited to what's offered by
the LSM framework, so even writing an equivalent to the RBAC
implementation isn't possible without going through the political work
of convincing many maintainers to add many more hooks, etc.

The LSM support (beyond ptrace_scope from Yama) was disabled in
core/linux seeing as it wasn't receiving any userspace report in the
repositories and many people don't like the auditing.

> If you were providing an alternative kernel temporarily as a
> testing-ground for things that would eventually get integrated in our
> main kernel, I'd be all for it. But the way I see it, everyone agrees
> that grsec is never going upstream and that this is not something we
> could ever integrate in the main kernel, so I think we should be very
> careful about splitting efforts which could have otherwise benefited
> the whole distro (such as support for AppArmor, TOMOYO, SELinux,
> whatever).
> 
> In short, work on grsec if you want, but please let's not use that as
> an excuse to discourage people from working on similar features for
> the main kernel.

I have no problem with someone else working on it, but as far as I know
there are no other developers or trusted users interested in doing this
kind of work.

Anyway, there is simply no similar support upstream. It has taken over a
decade for a few sysctl flags to enable some of the miscellaneous
features from grsecurity. You'll encounter a *lot* of resistance trying
to upstream work as Kees Cook has been doing. Yama exists because the
kernel developers refused to support ptrace_scope in the core kernel...
and it's a tiny feature.

-------------- 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/20140419/94edb7d6/attachment-0001.asc>