Subject: Re: chroot: why super-user only?
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 01/23/2003 18:04:13
>> Put another way, under what conditions is it safe for a non-root
>> user to chroot(2)?
> This falls into the same category of "Under what conditions is it
> safe to point a loaded gun at oneself?", really.

Well, sort of.  For example, your sample scenario is impossible if
there are no user-writable directories on the filesystem containing
/etc/spwd.db and /usr/bin/su (if those are even the same filesystem).

> You would need to disallow set-id execution (and, arguably, device
> access.)

Not necessarily; it's enough - for this scenario - for there to be no
set-id executables present in the chroot sandbox at any time (not just
when chroot is run, but at any time when the chroot is live).  Or at
least for any that are present to be suitably paranoid about what they
read from the filesystem (which set-id executables usually aren't,
unless they have been written with defenses against such attacks
specifically in mind, and often not even then).

Of course, that can't easily be enforced, which is one reason chroot is
restricted.

It may be enough, for example, if the chroot point is on a filesystem
mounted by the calling user (which means that non-root users have
MNT_NOSUID enforced).  However, this is vulnerable to somehow (social
engineering?) getting root to mount a filesystem with a set-id
executable under the chroot point.

In short, it's done because figuring out what the conditions are is
hairy, and ensuring they're satisfied is very hard.  So it's both
easier and safer to punt and allow it only for root.  (One could make
an argument that most uses of it aren't the sort of thing users should
be doing without the support of the local administrator anyway.  I'm
not sure I'd go that far, myself.)

It might be enough if non-root chroot() were to set a flag on the
process so that it will never, ever, honor set-id on an executable (and
this flag is copied on fork and cannot be cleared by anything).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B