On 19/04/14 05:25 PM, Tom Gundersen wrote:
On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay <danielmicay@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.