On Tue, 12 Jul 2011 04:49:48 +0000, Taylor R Campbell wrote:
Perhaps there's a similar hole in your kauth secmodel that letschrooted processes rewrite arbitrary kernel memory (even without, say,a buffer overflow bug in the kernel); perhaps you need another tinytweak to close the hole. For instance, perhaps from within the chrootI can use fhopen to replace /bin/sh outside the chroot by a program that opens /dev/kmem and does horrible things. So what is the security policy you mean to enforce by blocking pathsinto the kernel with kauth? For every `destructive modification' thatcan be done to the system, what is every path into the kernel that leads to that modification? Have you blocked all such paths in your kauth secmodel? If not, what does an operator need to do to set up the chroot to get your kauth secmodel to block them?
Well, normally (except for bugs or conception errors), kauth is supposed to sit at every point in kernel where authorization has to be enforced.
It's quite some feat to have a fine-grained framework where each of his rule has no impact on another one, especially when you have millions lines of code involved; it may even lead to contradictions when you start adding negations, e.g.:
- foo is allowed to load modules - foo is /not/ allowed to access /root/ Which is evidently flawed.The purpose of his patch is to make system's information gathering more difficult from a chroot, and raise process containment a bit further. I doubt that the ultimate goal is to completely protect system from exploitation, especially when the chroot is improperly built and run.
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost