Steven M. Bellovin | 2 Nov 01:49 2005

replace chroot() with a chroot overlay file system?

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.

mcr | 2 Nov 16:45 2005
Picon

Re: replace chroot() with a chroot overlay file system?


>>>>> "Steven" == Steven M Bellovin <smb <at> cs.columbia.edu> writes:
    Steven> I'm thinking out loud here, so I may easily be confused,
    Steven> but...

    Steven> What if we replaced the chroot() system call by an overlay
    Steven> file system, mounted over some subtree?  The advantage is
    Steven> that that file system could be mounted read-only, nosuid,
    Steven> nodev, even noexec.

So,
	chroot("/my/foo");

becomes the same as something:
	mount -o ro,nosuid,noexec,nodev -t union /something /my/foo
	chroot /my/foo

(where /something might even be /)

I'm a bit ignorant of union file systems wrt: "nodev". If the lower file
system has "dev" enabled, and the upper file system has "nodev", does
that mean that the /dev entries show through, but that when you try to
create new ones, they don't work?

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
(Continue reading)

David Maxwell | 2 Nov 17:35 2005
Picon

Re: replace chroot() with a chroot overlay file system?

On Tue, 01 Nov 2005, 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.

One problem that comes to mind - what if you want multiple processes
chroot()ed into the same space? It seems that you would end up with
stacked mounts, and the older ones can't be unmounted via the exising
stackable filesystem model, until the newer ones are released.

Additionally, is it possible you might want 'noexec' etc, to apply to
only some of the processes in that chrooted area? I don't that works
with the filesystem thought.

--

-- 
David Maxwell, david <at> vex.net|david <at> maxwell.net -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
					      - Jamie Woods

Brett Lymn | 3 Nov 01:33 2005
Picon

Re: replace chroot() with a chroot overlay file system?

On Wed, Nov 02, 2005 at 10:45:43AM -0500, mcr wrote:
> 
> So,
> 	chroot("/my/foo");
> 
> becomes the same as something:
> 	mount -o ro,nosuid,noexec,nodev -t union /something /my/foo
> 	chroot /my/foo
> 
> (where /something might even be /)
> 

At which point I would be worried about a privilege escalation leading
to my password database being snatched for offline cracking.  The nice
thing about chroot is that you don't have the encrypted passwords
laying about.

--

-- 
Brett Lymn

Daniel Carosone | 3 Nov 03:10 2005
Picon

Re: replace chroot() with a chroot overlay file system?

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
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" :-)

 * 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?

--
Dan.
Steven M. Bellovin | 3 Nov 03:20 2005

Re: replace chroot() with a chroot overlay file system?

In message <20051103021022.GX24589 <at> 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).

(Continue reading)

Michael Richardson | 3 Nov 18:08 2005
Picon

Re: replace chroot() with a chroot overlay file system?


>>>>> "Brett" == Brett Lymn <blymn <at> baesystems.com.au> writes:
    >> So, chroot("/my/foo");
    >> 
    >> becomes the same as something: mount -o ro,nosuid,noexec,nodev -t
    >> union /something /my/foo chroot /my/foo
    >> 
    >> (where /something might even be /)
    >> 

    Brett> At which point I would be worried about a privilege
    Brett> escalation leading to my password database being snatched for
    Brett> offline cracking.  The nice thing about chroot is that you
    Brett> don't have the encrypted passwords laying about.

  right, there are different reasons for chroot().
  Sometimes, you *do* want to be able to read stuff. Maybe even
passwords. (think pop daemon...) Sometimes you do not.

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Bill Studenmund | 4 Nov 03:00 2005
Picon

Re: replace chroot() with a chroot overlay file system?

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.

The problem I see with nodev is that that means we don't have /dev/null. 
My understanding is that chroot environments often need a _few_ devices, 
and with nodev they get none.

Also, overlay file systems add vnode overhead. If we need it, it's good. 
But I'm not sure if I feel comfortable with us making one for each chroot 
environment.

I'd say that either systrace or something like Solaris's capabilities 
would be a good route to go. If we make making device nodes a "capability" 
and the chroot processes don't have it, no new devices. :-)

Take care,

Bill
Matthias Scheler | 4 Nov 14:34 2005
Picon

Re: replace chroot() with a chroot overlay file system?

In article <20051102004959.D95A13BFCE0 <at> berkshire.machshav.com>,
	"Steven M. Bellovin" <smb <at> cs.columbia.edu> writes:
> 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.

You can't use "nodev":

tron <at> colwyn:~>ls -l /var/chroot/named/dev
total 0
crw-rw-rw-  1 root  wheel   2, 2 Dec 27  2003 null
cr--r--r--  1 root  wheel  46, 0 Mar 12  2002 random

And without "nodev" somebody with root privileges can still escape
or at least cause damage. Maybe we need a "nomakedev" option?

	Kind regards

--

-- 
Matthias Scheler                                  http://scheler.de/~matthias/

Curt Sampson | 5 Nov 06:16 2005
Picon

Re: replace chroot() with a chroot overlay file system?

On Fri, 4 Nov 2005, Matthias Scheler wrote:

> And without "nodev" somebody with root privileges can still escape
> or at least cause damage. Maybe we need a "nomakedev" option?

While we're talking about this, the first thing that occurred to me when
this thread started was that Steve seems to have the exact opposite
problem that I do. (I'm not sure why.)

I used always to mount /var nodev,nosuid, just like /tmp. (I reckon
if there's a world writable directory in there, nodev,nosuid can't
hurt.) But I can't do that any more because of stuff like ntp, which is
chrooted into /var/chroot, and needs a device.

cjs
--

-- 
Curt Sampson        <cjs <at> cynic.net>         +81 90 7737 2974
   Make up enjoying your city life...produced by BIC CAMERA


Gmane