Relaxing strict chroot checks on recent Linux kernels?

[Ángel González]

On 04/02/13 22:49, Andy Lutomirski wrote:
> On Sat, Feb 2, 2013 at 1:26 PM, Ángel González <keisial at gmail.com> wrote:
>> 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.
Oh, good. You're right. I was considering joining the mount namespace as
getting the whole view of the fs tree.


>>> 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?
I haven't tested, but I'm quite sure it could happen. Note how glibc
uses dynamic
name service switch libraries. If /etc/nsswitch.conf contained entries
pointing to
libraries not-yet-loaded, and you can trigger them to be loaded by the
internal-stfp,
I suspect it would load them from inside the chroot.


>> 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.
It could be summarised as “Giving someone a sftp-only account shouldn't
allow
them to execute code” :)