Andy Lutomirski
2013-Feb-02 01:43 UTC
Relaxing strict chroot checks on recent Linux kernels?
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.
Ángel González
2013-Feb-02 21:26 UTC
Relaxing strict chroot checks on recent Linux kernels?
On 02/02/13 02:43, Andy Lutomirski wrote:> 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.I'm a bit concerned about a scenario where you have shell access both unchrooted and unsafe chroot + PR_SET_NO_NEW_PRIVS, and then you get into the chroot with setns(2). Although setns seems to require CAP_SYS_ADMIN, so it the vulnerability might be in such case in the application doing that.> Yes, this would be Linux-specific functionality (and hence somewhat > odd for sshd), but it would be very useful.I guess it could be added as a new flag, only honored on Linux for now (just as the sandboxing used is system-dependant).> 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.I suspect there's another condition there, although not explicit in your mail: the sftp account shall not be able to write that directory.> 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.It is tempting to add an option to chroot to unsafe directories when using internal-sftp. After all, you are not executing programs placed there... However, even when using internal-sftp there's the problem of placing a malicious library which is then dynamically loaded by the internal-sftp process (eg. to perform an uid lookup). Not applicable to the read-only process, but if there was such option of untrusted-chroot for the sftp-only, it would be applied to rw-sftp account. Which per the above, even with PR_SET_NO_NEW_PRIVS, could be escalated from sftp-only to a remote shell. :(
Damien Miller
2013-Feb-03 21:55 UTC
Relaxing strict chroot checks on recent Linux kernels?
On Fri, 1 Feb 2013, Andy Lutomirski wrote:> 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.You will be able to do this with sftp-server in CVS current. It support a flag to override the user's home directory, so you can do something like: Subsystem sftp internal-sftp -l verbose -d /files ChrootDirectory /chroot/%u The sftp session will start in /files (or /chroot/$USER/files objectively). IIRC the no-new-privs thing was only safe if you were also using seccomp, but I need to check. It seems like a reasonable thing to enable for sftp-server unconditionally. I probably wouldn't want to rely on it though, as there are probably bad things that can be done even without raising privs in the process that launches the attack. E.g. rewrite /etc/ld.so.preload. Remember that ChrootDirectory isn't just for sftp. -d
Apparently Analagous Threads
- OpenSSH + chroot + SELinux = broke
- [Bug 1461] New: session.c: don't chdir() after chroot() if chroot_path==pw->pw_dir
- Directory permissions in chroot SFTP
- [Bug 177] provide chroot option for sftp-server
- internal-sftp and logging not working with Fedora and chroot using 5.5?