Let's entertain the /kern notion for just one more minute; assuming 
that each object has its own permissions (which would show up as file 
or directory permissions), then there's no problem mounting /kern 
itself anywhere you like (indeed, it can be an unprivileged mount - 
anyone can do it).

Now, in the case of a chroot(2)'d environment, I hear you say, "Ah 
hah! Suppose a clever attacker gains root inside the box, and then 
mounts /kern? He can modify various global system operational 
parameters!"

Well, yeah. Does sysctl(2) prevent that?

What sysctl variables does one typically need inside the chroot(2) box, anyway?

8th Edition and Plan 9 have some very clever mechanisms for providing 
for a standard, but individual execution environment by arranging the 
filesystem name space in interesting ways with mount(2). Again, the 
idea was simple: make almost everything into a file, and then 
manipulate as necessary with existing tools. I think we'd do well to 
adopt some of them, and thereby get rid of a raft of specialized 
system calls...

	Erik <fair@clock.org>