Re: RFC: New security model secmodel_securechroot(9)

[Taylor R Campbell <campbell+netbsd%mumble.net@localhost>]

(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 <cheusov%tut.by@localhost>

   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?