Relaxing strict chroot checks on recent Linux kernels?

[Ángel González]

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.  :(