Re: [PATCH] User chroot

Re: [PATCH] User chroot

[Paul Menage]

In article <0C01A29FBAE24448A792F5C68F5EA47D1205FB@nasdaq.ms.ensim.com>,
you write:
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot.  In other
>words, it's all pain, no gain.
>

It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP server) that wanted to be absolutely sure that neither it
nor any of its libraries were being tricked into following a bogus
symlink, or a "/../" in a passed filename. After initialisation, the
daemon could chroot() into its data directory, and safely only serve
the set of files within that directory hierarchy.

This could be regarded as the wrong way to solve such a problem, but
this kind of bug seems to be occurring often enough on BugTraq that it
might be useful if you don't have the resources to do a full security
audit on your program (or if the source to some of your libraries
isn't available).

Paul

Re: [PATCH] User chroot

[H. Peter Anvin]

Followup to:  <E15F3KH-0003fd-00@pmenage-dt.ensim.com>
By author:    Paul Menage <pmenage@ensim.com>
In newsgroup: linux.dev.kernel
> 
> It could potentially be useful for a network daemon (e.g. a simplified
> anonymous FTP server) that wanted to be absolutely sure that neither it
> nor any of its libraries were being tricked into following a bogus
> symlink, or a "/../" in a passed filename. After initialisation, the
> daemon could chroot() into its data directory, and safely only serve
> the set of files within that directory hierarchy.
> 
> This could be regarded as the wrong way to solve such a problem, but
> this kind of bug seems to be occurring often enough on BugTraq that it
> might be useful if you don't have the resources to do a full security
> audit on your program (or if the source to some of your libraries
> isn't available).
> 

If the source to some of your libraries aren't available, you have no
clue when/why/if they will try to access other files in the
filesystem.  Since libc WILL do this, a random chroot() breaks libc
(unless you can set up a proper root environment), and therefore
pretty much anything else is pointless.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] User chroot

[David Wagner]

Paul Menage  wrote:
>It could potentially be useful for a network daemon (e.g. a simplified
>anonymous FTP server) that wanted to be absolutely sure that neither it
>nor any of its libraries were being tricked into following a bogus
>symlink, or a "/../" in a passed filename. After initialisation, the
>daemon could chroot() into its data directory, and safely only serve
>the set of files within that directory hierarchy.
>
>This could be regarded as the wrong way to solve such a problem, but
>this kind of bug seems to be occurring often enough on BugTraq that it
>might be useful if you don't have the resources to do a full security
>audit on your program (or if the source to some of your libraries
>isn't available).

Or even where you have done a full security audit on your program, it is
often still useful to have backup protection.  Belt and suspenders[*],
and all that.

[*] For those who are not familiar with the reference: If you really,
    really want to avoid getting caught with your pants down, you might
    wear both a belt and a pair of suspenders.

Re: [PATCH] User chroot

[David Wagner]

It is not rocket science to populate a chroot environment with enough
files to make many interesting applications work.  Don't expect a general
solution---chroot is not a silver bullet---but it is useful.  (Note also
that whether you can populate a chroot environment sufficiently is roughly
independent of whether you called chroot(2) with root privileges or not.)

Re: [PATCH] User chroot

[Mohammad A. Haque]

Paul Menage wrote:
> This could be regarded as the wrong way to solve such a problem, but
> this kind of bug seems to be occurring often enough on BugTraq that it
> might be useful if you don't have the resources to do a full security
> audit on your program (or if the source to some of your libraries
> isn't available).

Why do this in the kernel when it's available in userspace?

http://freshmeat.net/projects/rj/

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/ 
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Re: [PATCH] User chroot

[Paul Menage]

>Paul Menage wrote:
>> This could be regarded as the wrong way to solve such a problem, but
>> this kind of bug seems to be occurring often enough on BugTraq that it
>> might be useful if you don't have the resources to do a full security
>> audit on your program (or if the source to some of your libraries
>> isn't available).
>
>Why do this in the kernel when it's available in userspace?
>
>http://freshmeat.net/projects/rj/
>

But only root can set this up, since you currently have to be root in
order to chroot(). The (only) advantage of the user chroot() patch would
be that users would be able to do the same thing without root
intervention.

Paul

Re: [PATCH] User chroot

[Alexander Viro]

On Tue, 26 Jun 2001, Paul Menage wrote:

> But only root can set this up, since you currently have to be root in
> order to chroot(). The (only) advantage of the user chroot() patch would
> be that users would be able to do the same thing without root
> intervention.

You need to be root to do mknod. You need to do mknod to create /dev/zero.
You need /dev/zero to get anywhere near the normal behaviour of the system.

Re: [PATCH] User chroot

[Paul Menage]

>
>You need to be root to do mknod. You need to do mknod to create /dev/zero.
>You need /dev/zero to get anywhere near the normal behaviour of the system.
>

Sure, but we're not necessarily looking for a system that behaves
normally in all aspects. The example given was that of a paranoid
network server that does all its initialisation in a normal environment,
and then does a chroot to its data directory. Or alternatively, forks
after accepting a connection, and the child does a chroot. No need to be
able to exec other programs, etc. Such a daemon is certainly possible,
as I've written one myself. But it had to be started by root, rather
than by a normal user.

I'm not claiming that the user chroot patch is necessarily useful enough
to be included in the standard kernel - merely that it does have some
real-world uses.

Paul

Re: [PATCH] User chroot

[David Wagner]

Mohammad A. Haque wrote:
>Why do this in the kernel when it's available in userspace?

Because the userspace implementations aren't equivalent.
In particular, it is not so easy for them to enforce the following
restriction:
  (*) If a non-root user requested the chroot, then setuid/setgid
      bits won't have any effect under the new root.
The proposed kernel patch respects (*), but I'm not aware of any
user-level application that ensures (*) is followed.

(Also, there is the small matter that the user-level implementations
are only usable by root, or are setuid root.  The latter is only a
minor difference, though, IMHO.)

Re: [PATCH] User chroot

[Kai Henningsen]

pmenage@ensim.com (Paul Menage)  wrote on 26.06.01 in <E15F4tx-0003sA-00@pmenage-dt.ensim.com>:

> >You need to be root to do mknod. You need to do mknod to create /dev/zero.
> >You need /dev/zero to get anywhere near the normal behaviour of the system.
> >
>
> Sure, but we're not necessarily looking for a system that behaves
> normally in all aspects. The example given was that of a paranoid
> network server that does all its initialisation in a normal environment,
> and then does a chroot to its data directory. Or alternatively, forks
> after accepting a connection, and the child does a chroot. No need to be
> able to exec other programs, etc. Such a daemon is certainly possible,
> as I've written one myself. But it had to be started by root, rather
> than by a normal user.

Aah - in that case, it seems the absence of /dev/zero might even be an  
advantage, making it impossible to exec (most) programs.


MfG Kai

Re: [PATCH] User chroot

[Chris Wedgwood]

On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:

> You need /dev/zero to get anywhere near the normal behaviour of the
> system.

Not commenting on the original patch, I think requiring /dev/zero for
a 'usable' system should be considered a [g]libc bug. /dev/zero should
be present, but if not, [g]libc should have fall-back mechanisms to
deal with things.


  --cw

Re: [PATCH] User chroot

[Alexander Viro]

On Wed, 27 Jun 2001, Chris Wedgwood wrote:

> On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:
> 
> > You need /dev/zero to get anywhere near the normal behaviour of the
> > system.
> 
> Not commenting on the original patch, I think requiring /dev/zero for
> a 'usable' system should be considered a [g]libc bug. /dev/zero should
> be present, but if not, [g]libc should have fall-back mechanisms to
> deal with things.

Frankly, glibc already has too many fall-back mechanisms of various kinds.
Several things Should Be There(tm). /dev/zero, /dev/null and /dev/tty are
definitely among them.

Re: [PATCH] User chroot

[Jorgen Cederlof]

On Wed, Jun 27, 2001 at 11:14:13 -0700, "H. Peter Anvin" wrote:
> > > If we only allow user chroots for processes that have never been
> > > chrooted before, and if the suid/sgid bits won't have any effect under
> > > the new root, it should be perfectly safe to allow any user to chroot.
> > 
> > Hmm. Dos this work with initrd and root pivoting?
> 
> At the moment, yes.  Once Viro gets his root-changes in, this breaks,
> since ALL processes will be chrooted.

What are those changes, and how will they break user chroots?

       Jörgen

Re: [PATCH] User chroot

[Albert D. Cahalan]

Sean Hunter writes:
> On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:

>> ln /dev/zero /tmp/zero
>> ln /dev/hda ~/hda
>> ln /dev/mem /var/tmp/README
>
> None of these (of course) work if you use mount options to
> restrict device nodes on those filesystems.

In which case, you can't boot. Think about it.

Never mind the method. One way or another, it is very often
possible for a normal users to set up a chroot environment
with the device files that are needed. Maybe they do something
obscene with the admin. :-) So chroot() is useful for users.

In my case, I _am_ the admin and I just don't want to run
every damn little test program and hack as root.

Re: [PATCH] User chroot

[Sean Hunter]

On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
> ln /dev/zero /tmp/zero
> ln /dev/hda ~/hda
> ln /dev/mem /var/tmp/README

None of these (of course) work if you use mount options to restrict device
nodes on those filesystems.

Sean

Re: [PATCH] User chroot

[Kai Henningsen]

hpa@zytor.com (H. Peter Anvin)  wrote on 27.06.01 in <9hd7pl$86f$1@cesium.transmeta.com>:

> By author:    kaih@khms.westfalen.de (Kai Henningsen)

> > jc@lysator.liu.se (Jorgen Cederlof)  wrote on 27.06.01 in
> > <20010627014534.B2654@ondska>:
> >
> > > If we only allow user chroots for processes that have never been
> > > chrooted before, and if the suid/sgid bits won't have any effect under
> > > the new root, it should be perfectly safe to allow any user to chroot.
> >
> > Hmm. Dos this work with initrd and root pivoting?
> >
>
> At the moment, yes.  Once Viro gets his root-changes in, this breaks,
> since ALL processes will be chrooted.

About what I expected. So you'd really want this flag to be resettable by  
root, if you go that way at all. Beginning to look a little too compley, I  
think.

The last time, ISTR we discussed some other, similar-but-different  
syscalls that made for more secure jails. I don't quite remember the  
details, though.


MfG Kai

Re: [PATCH] User chroot

[Andries.Brouwer]

> Not that the documentation on MAP_ANON is any good either
> but at least the mere existence of the flag is mentioned.

> Seriously:
> both features ought to be documented in the man pages
> (I did submit a man page too, back in 1996)

Ah yes, I see. We both wrote a man page, and each contained
stuff not in the other, and I asked you to merge them, but
then nothing happened anymore. Maybe I should merge them
myself.

[In case you do the merging: please distinguish clearly
between what is prescribed by POSIX (or SUSv2, or Austin draft 7)
and what is implemented by (g)libc or the Linux kernel.
I see that your version has prototypes like
	caddr_t mmap(caddr_t  addr, ...
but this caddr_t is typically from BSD, and is void * these days.]

Andries

Re: [PATCH] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> "Albert D. Cahalan" wrote:

>> BTW, it is way wrong that /dev/zero should be needed at all.
>> Such use is undocumented ("man zero", "man mmap") anyway, and
>> AFAIK one should use mmap() with MAP_ANON instead. Not that
>> the documentation on MAP_ANON is any good either, but at least
>> the mere existence of the flag is mentioned.
>
> RTFM(POSIX).

No manual entry for RTFM in section POSIX

Seriously:

1. both features ought to be documented in the man pages
   (I did submit a man page too, back in 1996)

2. it is slow and nasty to open /dev/zero for getting memory

Re: [PATCH] User chroot

[H. Peter Anvin]

"Albert D. Cahalan" wrote:
> 
> BTW, it is way wrong that /dev/zero should be needed at all.
> Such use is undocumented ("man zero", "man mmap") anyway, and
> AFAIK one should use mmap() with MAP_ANON instead. Not that
> the documentation on MAP_ANON is any good either, but at least
> the mere existence of the flag is mentioned.
> 

RTFM(POSIX).

	-hpa

Re: [PATCH] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> Albert D. Cahalan wrote:

>> Normal users can use an environment provided for them.
>>
>> While trying to figure out why the "heyu" program would not
>> work on a Red Hat box, I did just this. As root I set up all
>> the device files needed, along Debian libraries and the heyu
>> executable itself. It was annoying that I couldn't try out
>> my chroot environment as a regular user.
>>
>> Creating the device files isn't a big deal. It wouldn't be
>> hard to write a setuid app to make the few needed devices.
>> If we had per-user limits, "mount --bind /dev/zero /foo/zero"
>> could be allowed. One way or another, devices can be provided.
>
> Hell no!  This would give the user a way to subvert root or other
> system-provided things by having device nodes or such appear where
> they aren't expected.  NOT GOOD.

On every normal (default Red Hat or Debian at least) system
this is already trivial:

ln /dev/zero /tmp/zero
ln /dev/hda ~/hda
ln /dev/mem /var/tmp/README

So the user often can provide device nodes. The above is _worse_
than allowing "mount --bind ..." because the admin has to search
the whole filesystem to find such links.

Never mind that though; it doesn't matter how the devices are
created. Social engineering can work. Once the device problem
is taken care of, chroot() becomes useful for normal users.

BTW, it is way wrong that /dev/zero should be needed at all.
Such use is undocumented ("man zero", "man mmap") anyway, and
AFAIK one should use mmap() with MAP_ANON instead. Not that
the documentation on MAP_ANON is any good either, but at least
the mere existence of the flag is mentioned.

Re: [PATCH] User chroot

[H. Peter Anvin]

Followup to:  <83fdx$Z1w-B@khms.westfalen.de>
By author:    kaih@khms.westfalen.de (Kai Henningsen)
In newsgroup: linux.dev.kernel
>
> jc@lysator.liu.se (Jorgen Cederlof)  wrote on 27.06.01 in <20010627014534.B2654@ondska>:
> 
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits won't have any effect under
> > the new root, it should be perfectly safe to allow any user to chroot.
> 
> Hmm. Dos this work with initrd and root pivoting?
> 

At the moment, yes.  Once Viro gets his root-changes in, this breaks,
since ALL processes will be chrooted.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] User chroot

[Jorgen Cederlof]

hpa@zytor.com ("H. Peter Anvin") writes:

> Followup to:  <20010627014534.B2654@ondska>
> By author:    Jorgen Cederlof <jc@lysator.liu.se>
> In newsgroup: linux.dev.kernel
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits won't have any effect under
> > the new root, it should be perfectly safe to allow any user to chroot.
> 
> Safe, perhaps, but also completely useless: there is no way the user
> can set up a functional environment inside the chroot.

Why? Because he can't create device nodes?

First of all, if /dev is on the same file system as the new root, the
user can ln the device nodes he wants to wherever he wants them in the
new root. He can't change their permissions, but that should not be
necessary.

Since I use devfs, I can't do that. But I decided to try how much I
can do anyway. So I downloaded the big redhat 7.1 image from User-mode
Linux. I unpacked it and extracted it to a directory using User-mode
Linux. Since I was a normal user, I could not create any device nodes
so I left /dev empty.

I chrooted into the directory. Most things seemed to work. I couldn't
use ping, since it needs to be suid root, and ps didn't work for
obvious reasons, but besides that everything looked OK.

I started an Xnest and started a gnome-session in it. Now I ran into
trouble. Some programs complained that they could not open
/dev/null. I touched /dev/null and put a couple of zeroes in /dev/zero
just in case. Now everything worked just fine. Gnome started and I
could run every application included.

The only thing that didn't work was terminal emulators. If I had not
been using devfs, but had /dev on the same file system as /tmp or ~, I
could have linked the needed device nodes. If you want to, you can
have a daemon running outside the root to mirror selected parts of
/proc into new_root/proc.

There are more uses for chroot than running user desktops, as has been
pointed out by others. The same arguments as implementing chroot for
root still applies.

Securing network daemons without needing to be root can be useful. As
an extra bonus, cracked daemons are prevented from gaining root access
from buggy suid binaries.

I'm sure you can think of more uses. Don't assume it has no uses just
because you can't think of anything in two minutes. I tend to use it
quite often now when I am used to it, and I often find it frustrating
to work on computers without this patch.

        Jörgen

Re: [PATCH] User chroot

[David Wagner]

Jesse Pollard  wrote:
>2. Any penetration is limited to what the user can access.

Sure, but in practice, this is not a limit at all.

Once a malicious party gains access to any account on your
system (root or non-root), you might as well give up, on all
but the most painstakingly careful configurations.  That's why
chroot is potentially valuable.

Re: [PATCH] User chroot

[Marcus Sundberg]

hpa@zytor.com ("H. Peter Anvin") writes:

> Followup to:  <20010627014534.B2654@ondska>
> By author:    Jorgen Cederlof <jc@lysator.liu.se>
> In newsgroup: linux.dev.kernel
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits won't have any effect under
> > the new root, it should be perfectly safe to allow any user to chroot.
> 
> Safe, perhaps, but also completely useless: there is no way the user
> can set up a functional environment inside the chroot.

Huh? Why wouldn't you be able to set up a functional environment?
I can think of quite a lot of things you can do without device nodes
or /proc ...
Or are you referring to something else?

//Marcus
-- 
---------------------------------+---------------------------------
         Marcus Sundberg         |      Phone: +46 707 452062
   Embedded Systems Consultant   |     Email: marcus@cendio.se
        Cendio Systems AB        |      http://www.cendio.com

Re: [PATCH] User chroot

[Jesse Pollard]

daw@mozart.cs.berkeley.edu (David Wagner):
> H. Peter Anvin wrote:
> >By author:    Jorgen Cederlof <jc@lysator.liu.se>
> >> If we only allow user chroots for processes that have never been
> >> chrooted before, and if the suid/sgid bits won't have any effect under
> >> the new root, it should be perfectly safe to allow any user to chroot.
> >
> >Safe, perhaps, but also completely useless: there is no way the user
> >can set up a functional environment inside the chroot.
> 
> Why is it useless?  It sounds useful to me, on first glance.  If I want
> to run a user-level network daemon I don't trust (for instance, fingerd),
> isolating it in a chroot area sounds pretty nice: If there is a buffer
> overrun in the daemon, you can get some protection [*] against the rest
> of your system being trashed.  Am I missing something obvious?

1. The libraries are already protected by ownership (root usually).
2. Any penetration is limited to what the user can access.
3. (non-deskop or server) Does the administrator really want users
   giving out access to the system to unknown persons? (I know, it's not
   prevented in either case.. yet)
4. inetd already does this. Spawned processes do not have to run as root...
5. A chroot environment (to be usefull) must have libraries/executables for any
   subprocesses that may do an exec. It doesn't matter whether it is done
   by a user or by root, but with root, at least the administrator KNOWS
   that the daemon process is untrusted, and how many are there, and what
   accounts they are in... And can be assured that each gets a separate
   UID, does/does not share files (and which files)...
6. There is no difference in the interpretation of setuid files between a
   chroot environment, and  outside a chroot environment.

Wait for the Linux Security Module - you may have a better way to define
access controls that DO allow what you want.

> [*] Yes, I know chroot is not sufficient on its own to completely
>     protect against this, but it is a useful part of the puzzle, and
>     there are other things we can do to deal with the remaining holes.


-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: [PATCH] User chroot

[Admin Mailing Lists]

On 27 Jun 2001, David Wagner wrote:
> 
> Why is it useless?  It sounds useful to me, on first glance.  If I want
> to run a user-level network daemon I don't trust (for instance, fingerd),
> isolating it in a chroot area sounds pretty nice: If there is a buffer
> overrun in the daemon, you can get some protection [*] against the rest
> of your system being trashed.  Am I missing something obvious?
> 

if you don't mind running fingerd on a non-privleged (>1024) port.

-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                       Network Administrator/Engineer
thelittleprince@asteroid-b612.org       Intergrafix Internet Services

    "Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org                http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

Re: [PATCH] User chroot

[Marco Colombo]

On 27 Jun 2001, David Wagner wrote:

> H. Peter Anvin wrote:
> >By author:    Jorgen Cederlof <jc@lysator.liu.se>
> >> If we only allow user chroots for processes that have never been
> >> chrooted before, and if the suid/sgid bits won't have any effect under
> >> the new root, it should be perfectly safe to allow any user to chroot.
> >
> >Safe, perhaps, but also completely useless: there is no way the user
> >can set up a functional environment inside the chroot.
>
> Why is it useless?  It sounds useful to me, on first glance.  If I want
> to run a user-level network daemon I don't trust (for instance, fingerd),
> isolating it in a chroot area sounds pretty nice: If there is a buffer
> overrun in the daemon, you can get some protection [*] against the rest
> of your system being trashed.  Am I missing something obvious?

Just write a small program that chroots, drop privileges, and
execs the untrusted daemon.

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: [PATCH] User chroot

[Kai Henningsen]

jc@lysator.liu.se (Jorgen Cederlof)  wrote on 27.06.01 in <20010627014534.B2654@ondska>:

> If we only allow user chroots for processes that have never been
> chrooted before, and if the suid/sgid bits won't have any effect under
> the new root, it should be perfectly safe to allow any user to chroot.

Hmm. Dos this work with initrd and root pivoting?

MfG Kai

Re: [PATCH] User chroot

[Kai Henningsen]

hpa@zytor.com (H. Peter Anvin)  wrote on 26.06.01 in <3B395FE5.1070208@zytor.com>:

> Albert D. Cahalan wrote:
>
> >
> > Normal users can use an environment provided for them.
> >
> > While trying to figure out why the "heyu" program would not
> > work on a Red Hat box, I did just this. As root I set up all
> > the device files needed, along Debian libraries and the heyu
> > executable itself. It was annoying that I couldn't try out
> > my chroot environment as a regular user.
> >
> > Creating the device files isn't a big deal. It wouldn't be
> > hard to write a setuid app to make the few needed devices.
> > If we had per-user limits, "mount --bind /dev/zero /foo/zero"
> > could be allowed. One way or another, devices can be provided.
> >
>
>
> Hell no!  This would give the user a way to subvert root or other
> system-provided things by having device nodes or such appear where they
> aren't expected.  NOT GOOD.

Well, only allow them where you expect them then. That's easy enough.


MfG Kai

Re: [PATCH] User chroot

[H. Peter Anvin]

Albert D. Cahalan wrote:

> 
> Normal users can use an environment provided for them.
> 
> While trying to figure out why the "heyu" program would not
> work on a Red Hat box, I did just this. As root I set up all
> the device files needed, along Debian libraries and the heyu
> executable itself. It was annoying that I couldn't try out
> my chroot environment as a regular user.
> 
> Creating the device files isn't a big deal. It wouldn't be
> hard to write a setuid app to make the few needed devices.
> If we had per-user limits, "mount --bind /dev/zero /foo/zero"
> could be allowed. One way or another, devices can be provided.
> 


Hell no!  This would give the user a way to subvert root or other 
system-provided things by having device nodes or such appear where they 
aren't expected.  NOT GOOD.

	-hpa

Re: [PATCH] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> [somebody]

>> Have you ever wondered why normal users are not allowed to chroot?
>>
>> I have. The reasons I can figure out are:
>>
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>>   nasty things.
>>
>> * If root calls chroot and changes uid, he expects that the process
>>   can not escape to the old root by calling chroot again.
>>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
> Safe, perhaps, but also completely useless: there is no way the user
> can set up a functional environment inside the chroot.  In other
> words, it's all pain, no gain.

Normal users can use an environment provided for them.

While trying to figure out why the "heyu" program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
executable itself. It was annoying that I couldn't try out
my chroot environment as a regular user.

Creating the device files isn't a big deal. It wouldn't be
hard to write a setuid app to make the few needed devices.
If we had per-user limits, "mount --bind /dev/zero /foo/zero"
could be allowed. One way or another, devices can be provided.

Re: [PATCH] User chroot

[David Wagner]

H. Peter Anvin wrote:
>By author:    Jorgen Cederlof <jc@lysator.liu.se>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot.

Why is it useless?  It sounds useful to me, on first glance.  If I want
to run a user-level network daemon I don't trust (for instance, fingerd),
isolating it in a chroot area sounds pretty nice: If there is a buffer
overrun in the daemon, you can get some protection [*] against the rest
of your system being trashed.  Am I missing something obvious?

[*] Yes, I know chroot is not sufficient on its own to completely
    protect against this, but it is a useful part of the puzzle, and
    there are other things we can do to deal with the remaining holes.

Re: [PATCH] User chroot

[H. Peter Anvin]

Followup to:  <20010627014534.B2654@ondska>
By author:    Jorgen Cederlof <jc@lysator.liu.se>
In newsgroup: linux.dev.kernel
> 
> Have you ever wondered why normal users are not allowed to chroot?
> 
> I have. The reasons I can figure out are:
> 
> * Changing root makes it trivial to trick suid/sgid binaries to do
>   nasty things.
> 
> * If root calls chroot and changes uid, he expects that the process
>   can not escape to the old root by calling chroot again.
> 
> If we only allow user chroots for processes that have never been
> chrooted before, and if the suid/sgid bits won't have any effect under
> the new root, it should be perfectly safe to allow any user to chroot.
> 

Safe, perhaps, but also completely useless: there is no way the user
can set up a functional environment inside the chroot.  In other
words, it's all pain, no gain.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

[PATCH] User chroot

[Jorgen Cederlof]

Hi,

Have you ever wondered why normal users are not allowed to chroot?

I have. The reasons I can figure out are:

* Changing root makes it trivial to trick suid/sgid binaries to do
  nasty things.

* If root calls chroot and changes uid, he expects that the process
  can not escape to the old root by calling chroot again.

If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to allow any user to chroot.

Example:

user:~$ /usr/sbin/traceroute 127.1
traceroute to 127.1 (127.0.0.1), 30 hops max, 38 byte packets
 1  localhost (127.0.0.1)  6.658 ms  0.764 ms  0.613 ms
user:~$ /usr/sbin/chroot /
user:/$ /usr/sbin/traceroute 127.1
traceroute: icmp socket: Operation not permitted
user:/$ /usr/sbin/chroot /
/usr/sbin/chroot: cannot change root directory to /: Operation not permitted
user:/$ 

Is there any reason why this could not be the default behavior for the
official kernel?

             Jörgen


diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/CREDITS linux-2.4.6-pre5-devel/CREDITS
--- linux-2.4.6-pre5-vanilla/CREDITS	Sat Jun 23 02:00:54 2001
+++ linux-2.4.6-pre5-devel/CREDITS	Sat Jun 23 02:04:31 2001
@@ -497,6 +497,13 @@
 S: Fremont, California 94539
 S: USA
 
+N: Jörgen Cederlöf
+E: jc@lysator.liu.se
+D: User capabilities, user chroot
+S: Rydsvägen 258 A.36
+S: 584 34 Linköping
+S: Sweden
+
 N: Gordon Chaffee
 E: chaffee@cs.berkeley.edu
 W: http://bmrc.berkeley.edu/people/chaffee/
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/fs/exec.c linux-2.4.6-pre5-devel/fs/exec.c
--- linux-2.4.6-pre5-vanilla/fs/exec.c	Thu Apr 26 23:11:29 2001
+++ linux-2.4.6-pre5-devel/fs/exec.c	Sat Jun 23 02:04:31 2001
@@ -617,7 +617,7 @@
 
 	if(!IS_NOSUID(inode)) {
 		/* Set-uid? */
-		if (mode & S_ISUID)
+		if (mode & S_ISUID && capable(CAP_EXECSUID))
 			bprm->e_uid = inode->i_uid;
 
 		/* Set-gid? */
@@ -626,14 +626,15 @@
 		 * is a candidate for mandatory locking, not a setgid
 		 * executable.
 		 */
-		if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP))
+		if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)
+		    && capable(CAP_EXECSGID))
 			bprm->e_gid = inode->i_gid;
 	}
 
 	/* We don't have VFS support for capabilities yet */
-	cap_clear(bprm->cap_inheritable);
+	cap_clear_set_user(bprm->cap_inheritable);
 	cap_clear(bprm->cap_permitted);
-	cap_clear(bprm->cap_effective);
+	cap_clear_set_user(bprm->cap_effective);
 
 	/*  To support inheritance of root-permissions and suid-root
          *  executables under compatibility mode, we raise all three
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/fs/open.c linux-2.4.6-pre5-devel/fs/open.c
--- linux-2.4.6-pre5-vanilla/fs/open.c	Fri Feb  9 20:29:44 2001
+++ linux-2.4.6-pre5-devel/fs/open.c	Sat Jun 23 02:04:32 2001
@@ -421,9 +421,22 @@
 		goto dput_and_out;
 
 	error = -EPERM;
-	if (!capable(CAP_SYS_CHROOT))
+	if (!capable(CAP_SYS_CHROOT) && !capable(CAP_USER_CHROOT))
 		goto dput_and_out;
 
+	if (!capable(CAP_SYS_CHROOT)) {
+		cap_lower(current->cap_effective,   CAP_EXECSUID);
+		cap_lower(current->cap_permitted,   CAP_EXECSUID);
+		cap_lower(current->cap_inheritable, CAP_EXECSUID);
+		cap_lower(current->cap_effective,   CAP_EXECSGID);
+		cap_lower(current->cap_permitted,   CAP_EXECSGID);
+		cap_lower(current->cap_inheritable, CAP_EXECSGID);
+	}
+
+	cap_lower(current->cap_effective,   CAP_USER_CHROOT);
+	cap_lower(current->cap_permitted,   CAP_USER_CHROOT);
+	cap_lower(current->cap_inheritable, CAP_USER_CHROOT);
+	
 	set_fs_root(current->fs, nd.mnt, nd.dentry);
 	set_fs_altroot();
 	error = 0;
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/include/linux/capability.h linux-2.4.6-pre5-devel/include/linux/capability.h
--- linux-2.4.6-pre5-vanilla/include/linux/capability.h	Sat May 26 03:01:28 2001
+++ linux-2.4.6-pre5-devel/include/linux/capability.h	Sat Jun 23 02:04:32 2001
@@ -3,7 +3,7 @@
  *
  * Andrew G. Morgan <morgan@transmeta.com>
  * Alexander Kjeldaas <astor@guardian.no>
- * with help from Aleph1, Roland Buresund and Andrew Main.
+ * with help from Aleph1, Roland Buresund, Andrew Main and Jörgen Cederlöf.
  *
  * See here for the libcap library ("POSIX draft" compliance):
  *
@@ -277,6 +277,36 @@
 
 #define CAP_LEASE            28
 
+
+/**
+ ** Capabilities used by normal user processes
+ **
+ ** They are handled somewhat different from other capabilities -
+ ** they are not cleared unless you drop them by hand, and using them
+ ** doesn't set PF_SUPERPRIV.
+ **/
+
+/* Allow the suid bit on executables to have effect */
+
+#define CAP_EXECSUID         29
+
+/* Allow the sgid bit on executables to have effect */
+
+#define CAP_EXECSGID         30
+
+/* Allow user chroots. This should have no negative impact on system
+   security - using it drops CAP_EXECS{U,G}ID and CAP_USER_CHROOT.
+   CAP_USER_CHROOT is also dropped if you make a normal chroot, to
+   prevent a process with changed UID from breaking out. */
+
+#define CAP_USER_CHROOT      31
+
+
+#define CAP_USER_MASK (CAP_TO_MASK( CAP_EXECSUID ) | \
+                       CAP_TO_MASK( CAP_EXECSGID ) | \
+                       CAP_TO_MASK( CAP_USER_CHROOT ) )
+
+
 #ifdef __KERNEL__
 /* 
  * Bounding set
@@ -302,7 +332,7 @@
 #define CAP_EMPTY_SET       to_cap_t(0)
 #define CAP_FULL_SET        to_cap_t(~0)
 #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
-#define CAP_INIT_INH_SET    to_cap_t(0)
+#define CAP_INIT_INH_SET    to_cap_t(CAP_USER_MASK)
 
 #define CAP_TO_MASK(x) (1 << (x))
 #define cap_raise(c, flag)   (cap_t(c) |=  CAP_TO_MASK(flag))
@@ -337,12 +367,13 @@
      return dest;
 }
 
-#define cap_isclear(c)       (!cap_t(c))
+#define cap_isclear(c)       (!(cap_t(c) & ~CAP_USER_MASK))
 #define cap_issubset(a,set)  (!(cap_t(a) & ~cap_t(set)))
 
-#define cap_clear(c)         do { cap_t(c) =  0; } while(0)
-#define cap_set_full(c)      do { cap_t(c) = ~0; } while(0)
-#define cap_mask(c,mask)     do { cap_t(c) &= cap_t(mask); } while(0)
+#define cap_clear(c)          do { cap_t(c) &= CAP_USER_MASK; } while(0)
+#define cap_set_full(c)       do { cap_t(c) = ~0; } while(0)
+#define cap_mask(c,mask)      do { cap_t(c) &= cap_t(mask); } while(0)
+#define cap_clear_set_user(c) do { cap_t(c) = CAP_USER_MASK; } while(0)
 
 #define cap_is_fs_cap(c)     (CAP_TO_MASK(c) & CAP_FS_MASK)
 
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/include/linux/sched.h linux-2.4.6-pre5-devel/include/linux/sched.h
--- linux-2.4.6-pre5-vanilla/include/linux/sched.h	Sat May 26 03:01:28 2001
+++ linux-2.4.6-pre5-devel/include/linux/sched.h	Sat Jun 23 02:04:32 2001
@@ -701,7 +701,8 @@
 	if (cap_is_fs_cap(cap) ? current->fsuid == 0 : current->euid == 0)
 #endif
 	{
-		current->flags |= PF_SUPERPRIV;
+		if (!(CAP_TO_MASK(cap) & CAP_USER_MASK))
+			current->flags |= PF_SUPERPRIV;
 		return 1;
 	}
 	return 0;