LWN: Comments on "LSS: The kernel hardening roundtable"

Points of confusion

trasz — Tue, 11 Oct 2011 12:22:13 +0000

In other words, ptrace capability is an instant root.

LSS: The kernel hardening roundtable

trasz — Tue, 11 Oct 2011 12:19:15 +0000

Not sure why would anyone want to reimplement those, but regarding SELinux - FreeBSD already implements several Mandatory Access Control policies. Differently from Linux, they are stackable. This framework is also used by several commercial operating systems, including MacOS X.

LSS: The kernel hardening roundtable

Pawlerson — Tue, 11 Oct 2011 11:58:14 +0000

This looks nice as a propaganda which is typical for bsd fanboys. I'd like to know how many lines of code freebsd needs to implement SELinux? Entire Linux kernel?

Points of confusion

oak — Sat, 01 Oct 2011 20:09:12 +0000

> Well yes, capabilities exist, but they don't really work. The reason Cook gave is true, but misses the much larger failure: they only remove capabilities that are normally exclusive to root.

And even for root operations they seem to have too little granularity.

Ptrace capability is a good (worst?) example of this. You need it to read things like process maps & smaps files which many (resource usage measurement) tools need, but that capability allows also attaching, inspecting and changing other users process internals, not just inspect how many mappings they have and how much memory those mappings use. Also, instead of denying access to maps & smaps /proc files, lacking ptrace capability means that you get wrong (empty) content for those files...

Points of confusion

Jan_Zerebecki — Fri, 30 Sep 2011 22:44:22 +0000

> 4) "In the future, the team would also like to confine renderers based on where the data comes from, he said, so that all renderers running for a given site were protected from each other as well."

That sentence would make sense if one displayed site embedded something from a different security domain ( e.g. example.com embeds from google.com while you are authenticated by a cookie with google.com ; a whole site by iframe or an picture by img src ). The data comes from different domains and is displayed in one site but still needs to be protected from each other.

Points of confusion

Ross — Thu, 29 Sep 2011 16:42:30 +0000

Thanks for the very interesting write up. However I'm confused by the conversation at several points and I'm not sure if I'm being dense, something was lost in the writeup, or if the participants were saying confusing things and sometimes talking past each other :)

1) "Because the kernel is one "gigantic privileged application" it can't be protected against other privileged applications like X, Cook said."

Umm... would this be any better if the kernel were not privileged? It seems like the problem is that X is a gigantic privileged application and/or that the kernel requires it to be privileged at all. Or is there a point I'm missing?

2) 'Some of the attendees were skeptical of an expanded seccomp approach. Schaufler pointed out that there is already a mechanism in the kernel (capabilities) for reducing the impact of vulnerabilities, but "no one uses it". Cook was not convinced that the granularity of capabilities was really all that useful because the number of capability bits that are equivalent to root is so large.'

Well yes, capabilities exist, but they don't really work. The reason Cook gave is true, but misses the much larger failure: they only remove capabilities that are normally exclusive to root. Hopefully people aren't making Chrome setuid root.

3) "If the code is the documentation, it is impossible to have a bug"

Documentation is good, and important if you want people to code to your intent and not the implementation. However the statement isn't completely fair. Things like stack-smashes, double-frees, and dereferencing of bad pointers would be widely recognized as bugs even for code that doesn't have documentation to say it doesn't crash your system :)

4) "In the future, the team would also like to confine renderers based on where the data comes from, he said, so that all renderers running for a given site were protected from each other as well."

Is there something preventing this now? There's something strange about the sentence: I would almost think that it should be s/a given site/different sites/, but I think that already happens. Wouldn't renderers for the same site would seem to have data coming from the same place at least as much as renderers for different sites would?

LSS: The kernel hardening roundtable

Yorick — Thu, 22 Sep 2011 19:52:48 +0000

A capability-based model like Capsicum's would indeed be very nice to have for Linux, for many reasons:

It would give a much more useful environment than a stark read()/write()/_exit() isolation cell
It is based on sound reasoning that is easy to understand (principle of least authority, zero ambient authority)
It would force a healthy review of all the different namespaces in Linux, making us ask ourselves "is this really needed?", and useful ways of converting them into honest file descriptors
Properly done, it would practically give process containers for free
The Capsicum project itself has demonstrated feasibility and we roughly know what to expect from their experience, both in terms of implementation and use

Last time I looked, Capsicum hadn't really addressed resource limitations; this might be necessary in the long run, but is probably not stricly necessary for a first useful attempt.

LSS: The kernel hardening roundtable

trasz — Thu, 22 Sep 2011 07:23:50 +0000

Might be worth mentioning that FreeBSD already provides an "extended seccomp"; it's called Capsicum. In a talk (http://www.youtube.com/watch?v=raNx9L4VH2k) there is a nice table comparing the number of lines of code that it took to properly sandobox Chromium using different mechanisms - with Linux and seccomp, it was 11300 lines of code and it was still incomplete; with FreeBSD and Capsicum, it was 100 lines.

LSS: The kernel hardening roundtable

nix — Wed, 21 Sep 2011 11:35:36 +0000

Are the devs(on both sides) hard to work with?

Is the sun hot?

The kernel developers do not get on very well with pseudonymous developers who believe they already know everything and whose response to any criticisms or suggestions at all is imputations of malice. Actually, the latter is sufficient: see the kernel list's stellar record of cooperation with Joerg Schilling. (Or, for that matter, anyone at all's record of cooperation with Joerg Schilling.)

LSS: The kernel hardening roundtable

kragilkragil2 — Tue, 20 Sep 2011 08:41:58 +0000

Great article.
I was wondering the GRSecurity/PAX stuff has been around for ages. What are the reasons some of the good parts didn't end up in the kernel? Are the devs(on both sides) hard to work with? Did it take kernel.org and linux.com to go down to open maintainers eyes for security? Did everybody think complex stuff like SELinux would be the sufficient?

LSS: The kernel hardening roundtable

Julie — Sun, 18 Sep 2011 17:59:14 +0000

This is a great roundup. Thanks, Jake!

LSS: The kernel hardening roundtable

solardiz — Sat, 17 Sep 2011 13:33:59 +0000

Jake, thank you for this informative and well-written article!