Date: Sun, 13 Apr 2003 18:41:46 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Mark Shepard <mns@BEST.COM> Cc: freebsd-security@freebsd.org Subject: Re: chroot() as non-root user? Message-ID: <20030413154146.GB92320@sunbay.com> In-Reply-To: <5.2.0.9.2.20030413101417.022481b0@127.0.0.1> References: <5.2.0.9.2.20030413101417.022481b0@127.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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@sunbay.com Sunbay Software AG,
ru@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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+mYU6Ukv4P6juNwoRAjNaAJ4n8cni+m/6LgcrQoxMPKZ0tkVKWgCfX77s
AOJJeJwuWYZEZZycYM9oLzQ=
=l6XO
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030413154146.GB92320>