Re: RFC: New security model secmodel_securechroot(9)

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

You've listed a lot of details about how securechroot works.  Can you
elaborate a little on more precisely what its goal is, and (at least
very roughly) sketch a proof that the details you've implemented
accomplish that goal?

In particular, you say that `The securechroot security model is
intended to protect the system against destructive modifications by
chroot-ed processes.', and you give a list of operations that are
prohibited.  These are a little different -- destructive modifications
are what you are trying to prevent, and prohibiting operations are the
way you are blocking pathways into the kernel that lead to destructive
modifications.  (E.g., mknod is presumably not considered destructive
itself, but it can grant access to hardware devices that cause
mayhem.)

Can you be more specific about the destructive modifications you are
trying to prevent, and can you show (at least informally) that every
pathway in the kernel to them is blocked by the operations you have
prohibited, or at least show under what hypotheses these pathways are
blocked?  That is, what an operator needs to do in order to use a
securechroot safely?

For example, let's suppose I'm an operator and I naively populate
/securechroot/dev with `MAKEDEV all'.  At a cursory examination, it
seems to me that a uid 0 process in the securechroot could probably
write to /dev/rwd0d in the securechroot and cause mayhem that way.  If
so, presumably I ought not to have created rwd0d in the chroot.  But
what is it safe for me to do?  Do you have examples of safe use of
securechroots to contain practical applications?