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: 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: 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. Mark
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 -------------- 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
On Sun, Apr 13, 2003 at 10:20:35AM -0500, Mark Shepard wrote:
+> 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.
You can do this with CerbNG (avaliable at http://cerber.sourceforge.net).
Policy could looks like this:
#define NONSUID_PATH "/path/to/nonsuid/dir/*"
if (syscall == SYS_chroot && ruid > 0 &&
ismember(GET_GID("chroot"), groups)) {
reg[1] = realpath(arg[0]);
if (reg[1] !@ NONSUID_PATH) {
return(EPERM);
}
/* chdir first to that directory */
setsyscall(SYS_chdir);
reg[0] = call();
if (reg[0] != 0) {
return(reg[0]);
}
setsyscall(SYS_chroot);
/* give uid 0 for this syscall */
reg[0] = sucall();
if (reg[0] != 0) {
return(reg[0]);
}
log(LOG_INFO, "CerbNG:%s: %s(%s[%s]) (with euid 0).", pname,
syscallname, arg[0], reg[1]);
return(0);
}
From now on members of group ,,chroot'' are able to use chroot(2)
syscall
without uid 0 if they want to chroot to some directory in NONSUID_PATH.
--
Pawel Jakub Dawidek pawel@dawidek.net
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-security/attachments/20030414/bd24afab/attachment.bin