OpenSSH + chroot + SELinux = broke

[Darren Tucker]

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

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.