In message <20051103021022.GX24589@bcd.geek.com.au>, Daniel Carosone writes:
>
>
>On Tue, Nov 01, 2005 at 07:49:59PM -0500, Steven M. Bellovin wrote:
>> I'm thinking out loud here, so I may easily be confused, but...
>>=20
>> What if we replaced the chroot() system call by an overlay file
>> system, mounted over some subtree?  The advantage is that that file
>> system could be mounted read-only, nosuid, nodev, even noexec.
>
>Two points, stated somewhat facetiously for dramatic effect (or
>something):
>
> * This and some of the followup sounds a lot like you want (or might
>   soon afterwards want) per-process mounts.  While I can think of a
>   number of other potentially useful things to do with such an
>   animal, "if you want plan9 you know where to find it" :-)

Well, I do lean in that direction, and I have many more things I want 
to do with such a beast, but that's not what I'm leaning towards here.
>
> * Systrace is probably a far more effective way to express the
>   permissions you want your overlay to enforce than writing a new
>   filesystem each time - and if it's not, perhaps that's where
>   improvements should go?
>
I don't like systrace.  The rules are too complex, too hard to set up, 
and too inflexible.  File permissions are done by pathname-matching, 
which is always problematic (and historically has been error-prone).

chroot, for what it does, is quite simple.  The problem is that it's 
vulnerable to root in a number of ways, most seriously if the contained 
process can create device inodes.  I'm looking for ways to eliminate 
that risk.

I've seen the follow-ups; I just haven't had time to reply.  Maybe 
Friday I'll have time....

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb