Relaxing strict chroot checks on recent Linux kernels?

[Andy Lutomirski]

On Sat, Feb 2, 2013 at 1:26 PM, Ángel González <keisial at gmail.com> wrote:
> 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.

I don't think you can setns into someone else's fs context like that.
You could setns into someone else's mount namespace (with appropriate
privilege), but that shouldn't come with their choice of root
directory.

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

Relying on that seems like it's asking for trouble -- what if the sftp
account and the writer account colluded?  I'd like to see this done in
a way that it doesn't matter what's in the chroot 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).

Eek -- does that really happen?

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

Not sure I understand this part.

--Andy