can chroot be made safe for non-root?

can chroot be made safe for non-root?

Post by Eric Buddingto » Thu, 17 Oct 2002 08:00:05



I am eager to be able to sandbox my processes on a system without the
help of suid-root programs (as I prefer to have none of these on my
system).

Would it be reasonable to allow non-root processes to chroot(), if the
chroot syscall also changed the cwd for non-root processes?

Is there a reason besides standards compliance that chroot() does not
already change directory to the chroot'd directory for root processes?
Would it actually break existing apps if it did change the directory?

-Eric
(who wishes there were better ways to run untrusted code)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Philippe Troi » Thu, 17 Oct 2002 08:50:08



> I am eager to be able to sandbox my processes on a system without the
> help of suid-root programs (as I prefer to have none of these on my
> system).

Probably an impossible task...

Quote:> Would it be reasonable to allow non-root processes to chroot(), if the
> chroot syscall also changed the cwd for non-root processes?

No.

  fd = open("/", O_RDONLY);
  chroot("/tmp");
  fchdir(fd);

and you're out of the chroot.

Quote:> Is there a reason besides standards compliance that chroot() does not
> already change directory to the chroot'd directory for root processes?
> Would it actually break existing apps if it did change the directory?

Probably not. Make that: change the directory to chroot'd directory if
the current working directory is outside the chroot. That is, leave
the cwd alone if it is already inside the chroot.

Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by David Wagn » Thu, 17 Oct 2002 23:40:06



>Would it be reasonable to allow non-root processes to chroot(), if the
>chroot syscall also changed the cwd for non-root processes?

It might be reasonable.  It is a little bit tricky, as if you're not
careful, this can open up security holes.  However, one course project
in a class I taught two years ago proposed a way to safely allow non-root
processes to use chroot().  Look here:
  http://www.cs.berkeley.edu/~smcpeak/cs261/index.html

You might also be interested in the LSM project; in sandboxes like
SubDomain, Janus, SELinux, systrace, and the like; in privilege separation;
in OpenBSD's jail(); and similar topics.

Quote:>(who wishes there were better ways to run untrusted code)

Me, too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

can chroot be made safe for non-root?

Post by David Wagn » Thu, 17 Oct 2002 23:40:07




>> Would it be reasonable to allow non-root processes to chroot(), if the
>> chroot syscall also changed the cwd for non-root processes?

>No.

>  fd = open("/", O_RDONLY);
>  chroot("/tmp");
>  fchdir(fd);

>and you're out of the chroot.

Irrelevant.  If a process *wants* to voluntarily sandbox itself, it can
close all open file descriptors before sandboxing.

Please note that
  chroot("/tmp");
  fd = open("/", O_RDONLY);
  fchdir(fd);
does *not* let you escape from the sandbox.  This means that a process
can sandbox itself, and once sandboxed, it can no longer escape.
This functionality would be very useful for security purposes (see, e.g.,
"privilege separation").

It is true that there are some tricky issues here.  For instance, root
has many ways to escape from a chroot() jail, so you should never use
chroot() to confine processes running as root.  Also, if non-root users
can call chroot(), then there may be bad interactions if the chroot-ed
process later calls chroot() again, or execs a setuid program.

However, I believe all of these tricky issues can be dealt with.  See, e.g.,
  http://www.cs.berkeley.edu/~smcpeak/cs261/index.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Philippe Troi » Fri, 18 Oct 2002 00:10:08





> >> Would it be reasonable to allow non-root processes to chroot(), if the
> >> chroot syscall also changed the cwd for non-root processes?

> >No.

> >  fd = open("/", O_RDONLY);
> >  chroot("/tmp");
> >  fchdir(fd);

> >and you're out of the chroot.

> Irrelevant.  If a process *wants* to voluntarily sandbox itself, it can
> close all open file descriptors before sandboxing.

You missed the point.

If the process can be forced to run the above (possibly via a stack
overflow), then it is out of the chroot.

Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by David Wagn » Fri, 18 Oct 2002 00:20:08





>> >  fd = open("/", O_RDONLY);
>> >  chroot("/tmp");
>> >  fchdir(fd);

>> >and you're out of the chroot.

>> Irrelevant.  If a process *wants* to voluntarily sandbox itself, it can
>> close all open file descriptors before sandboxing.

>You missed the point.

>If the process can be forced to run the above (possibly via a stack
>overflow), then it is out of the chroot.

Ahh, yes.  Exactly so.  My apologies for missing your point.

Still, I don't think this is a big deal.  The problem is that if
a chroot-ed process can call chroot() again, it can escape from the
chroot jail.  There is one obvious solution: simply don't allow chroot-ed
process to call chroot() again.  This is addressed in the link I posted
previously.

So I still think that chroot() could plausibly be made safe for non-root
users.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Niels Provo » Fri, 18 Oct 2002 07:20:04


Quote:>I am eager to be able to sandbox my processes on a system without the
>help of suid-root programs (as I prefer to have none of these on my
>system).
>Would it be reasonable to allow non-root processes to chroot(), if the
>chroot syscall also changed the cwd for non-root processes?

You might want to look into systrace, see

  http://www.citi.umich.edu/u/provos/systrace/

Sandboxing your own applications does not require special privileges.
Policy generation is intuitive and interactive.  Thats means you can
generate your policies on the fly without complete knowledge of the
exact code paths an application takes.  (I run all my 3rd-party
software and most system daemons under systrace)

Policy violations are reported and can be resolved directly in
interactive mode.

To avoid setuid-root programs, systrace supports Privilege Elevation.

This is a novel feature that allows you to run an application without
special privileges.  The policy can momentarily elevate the privileges
of the application, for example to bind a reserved port or to create a
raw socket.  Basically, it allows as fine grained capabilities as
possible.

The Linux port is basically finished and should appear on the web page
in the next couple days.

Niels.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Pavel Mache » Sat, 19 Oct 2002 22:20:06


Hi!

Quote:> I am eager to be able to sandbox my processes on a system without the
> help of suid-root programs (as I prefer to have none of these on my
> system).

You can do that using ptrace. subterfugue.sf.net.
                                                                Pavel
--


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

can chroot be made safe for non-root?

Post by David Wagn » Sat, 19 Oct 2002 22:40:07



>> I am eager to be able to sandbox my processes on a system without the
>> help of suid-root programs (as I prefer to have none of these on my
>> system).

>You can do that using ptrace. subterfugue.sf.net.

ptrace() is ok, but it also has lots of disadvantages: performance,
expressiveness, security, assurance.  I've posted before on this mailing
list, at length, about them.  In short, ptrace() is not an ideal solution,
and a secure chroot() or other way to construct a jail/sandbox would
be better.  (LSM will be much better.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

can chroot be made safe for non-root?

Post by Shaya Potte » Sat, 19 Oct 2002 23:20:06




> >> I am eager to be able to sandbox my processes on a system without the
> >> help of suid-root programs (as I prefer to have none of these on my
> >> system).

> >You can do that using ptrace. subterfugue.sf.net.

> ptrace() is ok, but it also has lots of disadvantages: performance,
> expressiveness, security, assurance.  I've posted before on this mailing
> list, at length, about them.  In short, ptrace() is not an ideal solution,
> and a secure chroot() or other way to construct a jail/sandbox would
> be better.  (LSM will be much better.)

the problem with chroot() is that they dont nest.  If you get an fd
outside the chroot, you effectively broke the chroot.  Therefore, if
someone can get root inside the chroot, all they have to do is open an
fd, chroot somewhere else, then fchdir to that fd.

If however, one could provide even a single level of nesting, such that
a chroot outside of a chroot sets the first level, and any other chroot
after that sets the inner level, then even root wouldn't be able to
break out of the chroot (presuming it didn't bring any fd's into the
chroot w/ it).  

It might be nice to provide even more levels than this, but not sure if
one gain much by doing that and the add complexity might make it not
worthwhile.  Then again, even 2 levels might be too complex.  I've
actually thought a little of this in regards to some research I'm doing,
but haven't had a chance yet to persue, and see what would need to be
effected.  It would seem to come into play mostly on the path walking
algorithms, but that's from a very very cursory reading of the stuff.
anyone else have any ideas on this? Or am I crazy :)

thanks,

shaya

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by David Wagn » Sat, 19 Oct 2002 23:20:10



>the problem with chroot() is that they dont nest.

That's *a* problem, but not (IMHO) the most significant problem.
The biggest disadvantages with chroot() (as I see it) are:
 * not useable unless you're root
 * too coarse-grained
 * only protects the filesystem, but not other resources (e.g., the network)
 * not suitable for jailing root

Quote:> If however, one could provide even a single level of nesting, such that
> a chroot outside of a chroot sets the first level, and any other chroot
> after that sets the inner level, then even root wouldn't be able to
> break out of the chroot (presuming it didn't bring any fd's into the
> chroot w/ it).  

This is not quite right.  There are LOTS of other ways that root
can break out of a chroot.

Actually, I suspect that nested chroot()s may not be needed very
frequently, so I think a simpler approach may be simply to prevent
a chrooted process from calling chroot() again: i.e., prevent nesting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Shaya Potte » Sat, 19 Oct 2002 23:40:11




> >the problem with chroot() is that they dont nest.

> That's *a* problem, but not (IMHO) the most significant problem.
> The biggest disadvantages with chroot() (as I see it) are:
>  * not useable unless you're root

is this a problem from a security perspective, or a design perspective.
i.e. users should be able to chroot their processes, not to gain
security but just to be able to do things.  Or also for security?

Quote:>  * too coarse-grained

what exactly do you mean?

Quote:>  * only protects the filesystem, but not other resources (e.g., the

network)

yes, chroot doesn't make a jail, but chroot + other stuff can make a
jail, and chroot can give you the fs side for close to free (lost
performance that is)

Quote:>  * not suitable for jailing root

b/c root can break out easily, right? to jail root you need other stuff
as I said above.

Quote:

> > If however, one could provide even a single level of nesting, such
that
> > a chroot outside of a chroot sets the first level, and any other
chroot
> > after that sets the inner level, then even root wouldn't be able to
> > break out of the chroot (presuming it didn't bring any fd's into the
> > chroot w/ it).  

> This is not quite right.  There are LOTS of other ways that root
> can break out of a chroot.

how? the class way is the fchdir, but I guess there are others, but my
brain is not seeing them right now.

Quote:> Actually, I suspect that nested chroot()s may not be needed very
> frequently, so I think a simpler approach may be simply to prevent
> a chrooted process from calling chroot() again: i.e., prevent nesting.

well, this would prevent you from using chroot w/ processes that want to
chroot (running an ftpd inside of a chroot, dont some like to chroot for
anonymous access?), I've thought about that in regards to my research
related to our zap system, and I would rather not have to do that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Eric Buddingto » Sun, 20 Oct 2002 19:50:09



> > Would it be reasonable to allow non-root processes to chroot(), if the
> > chroot syscall also changed the cwd for non-root processes?

> No.

>   fd = open("/", O_RDONLY);
>   chroot("/tmp");
>   fchdir(fd);

> and you're out of the chroot.

I see. From my aesthetic, it would make sense for chroots to 'stack',
such that once a directory is made the root directory, its '..' entry
*always* points to itself, even after another chroot(). That would
prevent the above break (you could be outside the new root, but you
still couldn't back out past the old root), though perhaps at an
unacceptable in complexity.

I do like the idea of preventing multiple chroots, as a second option.

Thanks to everyone for all the useful comments.

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Bernd Eckenfel » Sun, 20 Oct 2002 21:10:07



> I do like the idea of preventing multiple chroots, as a second option.

this is not enough to allow chroot for non root. There are just too many
suid programs which rely on absolute path. So if one allows chroot() for
non-root users, the usage of suid/sgid must be forbidden, too.

Greetings
bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

can chroot be made safe for non-root?

Post by Hank Leininge » Sun, 20 Oct 2002 21:50:10





> > > Would it be reasonable to allow non-root processes to chroot(), if  
> > > the chroot syscall also changed the cwd for non-root processes?  

> > No.  

> > fd = open("/", O_RDONLY);  
> > chroot("/tmp");  
> > fchdir(fd);  

> > and you're out of the chroot.  
> I see. From my aesthetic, it would make sense for chroots to 'stack',  
> such that once a directory is made the root directory, its '..' entry  
> *always* points to itself, even after another chroot(). That would  
> prevent the above break (you could be outside the new root, but you  
> still couldn't back out past the old root), though perhaps at an  
> unacceptable in complexity.  

And not quite enough, if I understand your suggestion properly.  It's not  
necessary above to chroot or fchroot using fd; its existance is enough to  
monkey with things outside/above the chroot jail, which is unacceptable.  

Quote:> I do like the idea of preventing multiple chroots, as a second option.  

That's far from enough though.  You also must consider:  

-signals to non-chrooted processes  
-shared memory (maybe obsolete now with shmfs)  
-running a setuid file such as /bin/su which has been hardlinked in by  
  a process outside the jail, reading your bogus passwd file in the jail  
  (collusion/multifactor attack)  
-chmod +s a chrooted file, to be accessed by another, unprivileged UID  
  which is not jailed (collusion/multifactor attack)  
-ptrace non-chrooted processes  
-in addition, for root:  
  -open raw devices / mknod of block and char devices  
  -mount(2)  
  -various capabilities need to be dropped (sysctl, module loading, ...)  

Any of these allow a chrooted process to interact too much with the rest  
of the system, if not leading to outright, immediate chroot-breaking.  
Some of them can be protected against without kernel patching, just  
careful policing of chroot usage: don't ever chroot a UID who also has  
processes outside of chroot (or in a different jail); make the parent of  
the chroot dir inaccessible by non-chrooted processes / regular users,
dont't give write access/directory ownership anywhere under chroot, etc.  
Some can't be made safe(r) w/o help.  

I have a patch to do all of the above here (only for 2.2 atm):  
http://www.theaimsgroup.com/~hlein/hap-linux/  
Look for CONFIG_SECURE_CHROOT.  Double chroots are forbidden, but also, a  
warning is printed if a process attempts to chroot with an open fd to a  
directory (I decided against making the chroot call fail, as any software  
buggy enough to chroot with open directory fds is likely to not check the  
return value of chroot(2), and blindly continue on failure--even worse).  
I'd be happy to hear about (and fix ;) anything I've missed.  

IIRC, FreeBSD allow a chroot'ed process to chroot again if and only if
the  
new root is a subdirectory of the initial chroot.  This allows things
like  
traditional, chrooting anonymous FTP to be run under an initial chroot.    

Double-chroot would also be desirable if you wanted to, say, have init  
spawn some kind of supervisory daemon (or just /bin/login on a serial  
port) and then have *everything* else be chrooted, all multiuser daemons,  
etc.  Then a compromise can play all they want in the sandbox; you still  
have an opportunity for integrity checking tools, etc to run in a
somewhat  
trustworthy environment.  

--  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. run a non-root user's program from a non-root user

Hi Folks,

Here is the problem.

I have user A and user B (non-root users)

I need for user A to initiate a job as user B. How can this be done?

As you know, I can do this as root. I can start a process from root as
another user in the system (cron jobs come to my mind!) Is there a way
to do this for non-root users? I believe I need to be able to do
something like  as user A
"su - B" without being prompted for password.

Appreciate suggestions in advance.

Pasha

BTW: I am using AIX 4.3.10

2. ncpmount kills my system.

3. Is non-root for *only* the ppp console safe?

4. Redhat + 3com + Sb32 = Trouble

5. making /usr/lib/lpsched executable for non-root users

6. Question about threading in C

7. Making /etc/dhcpd.conf editable by non-root users

8. Printing accounting on Solaris (and CAP6.0)

9. wierd problem with non-root BASH (0.96 root and boot)

10. root privileges through non-root process?

11. From Root to non-Root on the fly => HOW?

12. Digital UNIX, C2 -> change root password as non-root

13. KDE start times different for root and non-root.