On 18/04/14 05:11 PM, Tom Gundersen wrote:
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:
https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation
I'm very happy that more people are now looking at security related things in Arch. Nice work!
To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.
Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.
There's nothing else hardening the kernel itself against exploitation, so containers (namespaces, seccomp-bpf) aren't going to benefit from any other work. I don't see much point in spending my time integrating an LSM when they're just layering on more complexity without fixing the lowest hanging fruit. The work that's done in grsecurity trickles into the kernel years later, so it's not really a dead end. I understand if touching any other packages is viewed as unacceptable and can work around that issue. The RBAC policies will be entirely centralized in the gradm package, and I can try to take the quirky approach of doing all of the PaX exceptions there. No other packages will be aware of anything going on, unless people feel like taking the completely optional step of making DKMS versions of modules. The only time spent on this is going to be my own. I've already spent far more time writing these mailing list responses than any amount of work I've put into improving security-related issues... speaking of development resources.
Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?
We do have ptrace_scope, protected_symlinks and protected_hardlinks enabled, which are bits of grsecurity that made it into the kernel after many years. The upstream kernel only has ASLR at all because PaX invented it in the early 2000s. We could enable dmesg_restrict / kptr_restrict but there's not much value until KASLR can be turned on. Even then, there's little value in KASLR (or ASLR) when many upstream maintainers simply don't care about breaking it by leaking addresses. Flipping on PIE for some executables would be an improvement, but it's a lot more valuable with the improved PaX ASLR.
Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?
I do really think it's the way to go. If it has to be walled off outside of the repositories, there's a lot less value in it. I'm unlikely to waste any more time trying to improve this aspect of the distribution if it's just shot down. To be perfectly honest, I didn't feel I had to ask for permission to maintain a 13 year old open-source project with 43 votes in [community] and had no idea there would be such a negative response. We have plenty of forks like graphicsmagick and even two entire desktop environments forked from GNOME (Mate and Cinnamon). There's at least one proprietary driver that's never going to be open-source let alone integrated upstream, and plenty of *truly* dead-end projects with no upstream (metacity!).