chroot() as non-root user?

[Ruslan Ermilov]

On Sun, Apr 13, 2003 at 10:20:35AM -0500, Mark Shepard wrote:
> 
> I suspect this has been asked before but I'll ask anyway.
> 
> Q1: Is it possible for a non-root process to perform a chroot?
> 
> My interest is this:  I have a typical ISP hosting account (verio; on a 
> FreeBSD 4.4 server.)  I'd like to install and run various CGI packages, yet 
> protect myself (and my email, and my .ssh keys) from bugs being exploited 
> in those CGI packages.  Chroot at the start of each CGI would do the trick, 
> but requires root.  I suspect the answer here is "only root can do this"... 
> which leads me to ask, in general:
> 
Yes.

> Q2:  Why is chroot() only available to root?  I'm aware of *one* security 
> issue:  if a non-root user can perform chroot(), they can alter the 
> name-space "seen" by setuid programs, and potentially compromise them 
> (assuming a user-writable directory [like /tmp] on the same partition as a 
> setuid program.)  Are there any other reasons?  (Besides the issues with 
> fchdir() which I assume are adequately fixed).  Assuming there aren't any 
> other issues leads to my last Q... Actually, a proposal:
> 
You could then staff ${CHROOTDIR}/etc with arbitrary password databases
that would allow you to su(1) there and do anything as root, e.g.,
ifconfig(8).

> Q3:  Why not allow non-root users to chroot() _as long as the target dir. 
> is on a partition mounted nosuid_?  Seems like this would be a simple 
> mechanism (both to understand and to implement) and would allow regular 
> users to take advantage of chroot to improve the security of scripts, CGIs, 
> etc.
> 
chroot(2) has no effect on the process's current directory; you
could hide (hard-link) the setuid program (su(1)) there, so
removing this protection on the syscall level can easily result
in a compromise.

chroot(8) changes the current working directory, but it's not
setuid root.


Cheers,
-- 
Ruslan Ermilov		Sysadmin and DBA,
ru at sunbay.com		Sunbay Software AG,
ru at FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20030413/9794ef34/attachment.bin