OpenSSH + chroot + SELinux = broke

[Derek Simkowiak]

    Darren,
    Thank you for your detailed reply.

    I have a follow-up question about the chroot exploit you mentioned:

Darren> "/The restriction is that the chroot directory heirarchy must be 
root-owned and not writable by the user, and it exists because of the 
danger involved if the user has write access to the chroot's / directory.

Consider what happens if, eg, the chroot directory is on the same 
filesystem as the real / and the user can create a hardlink to /sbin/su 
and their own /etc/passwd (or *any* setuid binary and their own 
/usr/lib/libc.so or ...)/ "


    Is this the same exploit you are referring to? (taken from 
http://kerneltrap.org/Linux/Abusing_chroot):


Mr_Z> /"If the mortal user has write access on any filesystem containing 
system binaries and files, they can hard-link to those binaries and 
files inside the chroot "jail" ahead of time. They can then put other 
files of their own creation in choice places (e.g. replace libc as 
someone suggested, or change other configuration files) and run SUID 
programs that are "too trusting" (e.g. programs that don't check for UID 
or GID=0 on libraries or config files) and get them to misbehave./

/Note that such an attack is much more difficult (impossible?) if mortal 
users do not have writable directories on the same filesystem as system 
libraries, executables and configuration scripts. Hard links generally 
do not cross filesystem boundaries."/

    (...and also referred to simply as a "chroot suid attack" here: 
http://www.lysator.liu.se/noid/user_chroot.html.)

    As you mentioned, this vulnerability is blocked by having a separate 
/home/ partition (or in the case of ISPConfig on Ubuntu, /var/ or 
/var/www/, because that's where home dirs are).  I've read about 
breaking out of a chroot() as a non-root user (by using ptrace() on a 
running, user-owned process outside of the jail), but all the other 
chroot() vulnerabilities I am aware of require the ability to run a 
process as root.


Thanks,
Derek

Darren Tucker wrote:
> Derek Simkowiak wrote:
>>     Hello,
>>     First, a big thank you to the OpenSSH devs.
>>
>> _    /Problem Summary:/
>> _    Chroot and SELinux don't get along.  This affects both the new 
>> (official) ChrootDirectory feature, as well as the older (3rd party) 
>> patch at http://chrootssh.sourceforge.net/.
>>
>> _    /History and repro:/
>> _    On March 21, 2008, Alexandre Rossi posted to this list with the 
>> subject: "*ChrootDirectory fails if compiled with SELinux support 
>> (whether or not using SELinux)*", and it can be read here:
>> http://www.gossamer-threads.com/lists/openssh/dev/42475
>>
>>     Alexandre described an SELinux failure with the following error 
>> message:
>>
>> ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: 
>> security_getenforce() failed
>>
>>     As far as I know, that bug still exists and has not been fixed.
>
> There were 2 problems, both relating to the fact that the /selinux 
> filesystem does not exist inside the chroot.
>
> 1) ssh_selinux_enabled() couldn't tell if selinux was enabled or not, 
> because after the chroot it couldn't read /selinux/whatever.  This was 
> fixed by caching the value of the previous call and made 
> ChrootDirectory work when selinux support was built in but selinux was 
> not enabled on the system.
>
> 2) sshd couldn't set up the selinux execution context for chrooted 
> sessions.  Again, that's because the /selinux filesystem doesn't exist 
> in the chroot.  I don't think there's nothing that sshd can do about 
> this, but it may be possible to make this work my also mounting 
> /selinux inside the chroot (if that's even possible and doesn't cause 
> problems for selinux, I'm not sure about either).
>
>>     I am now getting that exact same error message from SELinux, 
>> however, I am not using the ChrootDirectory feature.  Instead, I am 
>> using the chroot patch from this location:
>>
>> http://chrootssh.sourceforge.net/
> [...]
>>     I do not understand why using (or not using) a chroot'd directory 
>> can cause SELinux support to become either "enabled" or "disabled". 
>
> You'll have to ask the authors of the patch about its behaviour.
>
>> _    /Note and question about ChrootDirectory:/_
>>
>>     Finally, I want to throw in a quick end-user criticism of the new 
>> ChrootDirectory feature.  I need chroot() support in OpenSSH, but 
>> this new ChrootDirectory option is useless to me (and, I submit, to 
>> most other people who need chroot support in SSH).
>>
>>      I am using a standard "shared server" webhosting setup.  User 
>> files are based on the $HOME dir, which is used by Apache's UserDir 
>> (~/public_html/), suEXEC (which _/requires/_ that users' files be 
>> under their $HOME), procmail (to find ~/.procmailrc), Courier-IMAP 
>> (to find ~/Maildir/), SpamAssassin (to find ~/.spamassassin), and 
>> other applications (like SquirrelMail, TMDA, etc.) that expect to 
>> find per-user files in the user's $HOME. 
>
> The restriction is that the chroot directory heirarchy must be 
> root-owned and not writable by the user, and it exists because of the 
> danger involved if the user has write access to the chroot's / directory.
>
> Consider what happens if, eg, the chroot directory is on the same 
> filesystem as the real / and the user can create a hardlink to 
> /sbin/su and their own /etc/passwd (or *any* setuid binary and their 
> own /usr/lib/libc.so or ...)
>