Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: replace chroot() with a chroot overlay file system?
From: Steven M. Bellovin (smbcs.columbia.edu)
Date: Wed Nov 02 2005 - 20:20:41 CST
In message <20051103021022.GX24589bcd.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...
>> 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
> * 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
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