Relaxing strict chroot checks on recent Linux kernels?

[Andy Lutomirski]

On Sun, Feb 3, 2013 at 1:55 PM, Damien Miller <djm at mindrot.org> wrote:
> 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).

This dosn't really work -- I want to change the chroot target, not the
home directory.  Unless you mean that internal-sftp will pretend that
/files is the root, blocking '..' and '/' as ways to escape.

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

If it's not sufficient for chroot, then it's IMO buggy.  (I wrote it.)

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

Sure it is -- I'm using ForceCommand internal-sftp.  I agree that if
there's any way to get a non-no_new_privs program in a writable chroot
then there's a privilege escalation, but I only want sftp.

--Andy