Points of confusion

Posted Sep 29, 2011 16:42 UTC (Thu) by Ross (guest, #4065)
Parent article: LSS: The kernel hardening roundtable

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?

to post comments

Points of confusion

Posted Sep 30, 2011 22:44 UTC (Fri) by Jan_Zerebecki (guest, #70319) [Link]

> 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

Posted Oct 1, 2011 20:09 UTC (Sat) by oak (guest, #2786) [Link] (1 responses)

> 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

Posted Oct 11, 2011 12:22 UTC (Tue) by trasz (guest, #45786) [Link]

In other words, ptrace capability is an instant root.