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?
