(Sorry, I forgot to add in my last message that I am not subscribed to this list, so please cc me in replies.)
Date: Sun, 10 Jul 2011 21:57:03 +0300 From: Alexey Cheusov <[email protected]> As I said earlier my code is based solely on kauth(9) and I assume it is correct. Also I assume my code is correct because I tested it and I could not find any problems. That's not really what I was asking about. Simply being based on kauth(9) is not sufficient to enforce a useful security policy. What you have tested -- if I understand correctly from the rest of your message -- is that the front door is closed and locked, but someone clever could pick the lock, and someone very clever could walk in through the missing wall on the side. Suppose I take your kauth secmodel, and tweak it a little bit to allow rather than deny kmem access. This is a tiny change -- probably a one-line, one-token change to your code -- and it is still based solely on kauth, but the change has tremendously far-reaching consequences: processes with uid 0 in the chroot can now rewrite arbitrary kernel memory and bypass your whole kauth secmodel as they please, if there is a /dev/kmem in the chroot, which there will be if you use the usual procedure of `untar sets && sh MAKEDEV all' to populate the chroot. Such a tiny change makes a world of difference in a kauth secmodel to the security policy it actually enforces. This tweaked kauth secmodel might prevent a little accidental damage from buggy programs in the chroot, but it doesn't really enforce any security policy against malicious attackers at all. Perhaps there's a similar hole in your kauth secmodel that lets chrooted processes rewrite arbitrary kernel memory (even without, say, a buffer overflow bug in the kernel); perhaps you need another tiny tweak to close the hole. For instance, perhaps from within the chroot I 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 paths into the kernel with kauth? For every `destructive modification' that can 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?
