Relaxing strict chroot checks on recent Linux kernels?

Andy Lutomirski luto at amacapital.net
Sat Feb 2 12:43:41 EST 2013


At the risk of beating a dead horse, I'd like to see the chroot
security checks relaxed a bit.  On newer Linux kernels, there's a
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) that prevents privilege
elevation (via setuid binaries, etc) for the caller and all of its
descendants.  That means that chroot(untrusted directory),
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), setreuid(uid, uid), execve(a
shell) is safe [1], even if the user can hardlink setuid programs into
the target directory.

Yes, this would be Linux-specific functionality (and hence somewhat
odd for sshd), but it would be very useful.

Here's why I want this: I have a server that has a bunch of data files
on it.  I want to create an account, used for sftp only, to allow
other servers to download certain files off of a particular directory
on this server.  That directory *can't* be writable only by root;
other users populate it.

For the time being, I've hacked around it using ACLs -- there's a
longstanding bug^Wfeature in openssh that causes it to ignore acls
when "validating" permissions.  But please consider allowing
ForceCommand internal-sftp in conjunction with ChrootDirectory to
safely skip permission checks on Linux kernels that are new enough to
use PR_SET_NO_NEW_PRIVS.

[1] Unless sshd itself is chrooted, in which case this might be usable
to break out of that chroot.  But the strict permission checks don't
help prevent that at all, so this isn't new.

Thanks,
Andy

P.S. openssh on Linux should probably set no_new_privs whenever
running its internal sftp server, regardless of whether it's
chrooting.


More information about the openssh-unix-dev mailing list