OpenSSH + chroot + SELinux = broke

[Derek Simkowiak]

    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.

    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/

    This patch works differently than the new ChrootDirectory, but does 
a similar thing.  It calls chroot() (and modifies pw->pw_dir) before 
calling the SELinux function ssh_selinux_setup_exec_context(pw->pw_name) 
in session.c, in function do_setusercontext().

    I get the error if I try to set up a user with a chroot'd home 
directory.  (I do this by adding "/./" into a user's home dir, which is 
how that patch works... see the patch docs for details on usage.)

    One possible lead as to the cause of this bug is in the debug 
output.  If I do /not/ use a chroot'd home directory for my user, then 
everything works, and the debug output shows this line:

debug1: SELinux support disabled

    But then, if I /do/ add the "/./" to the user's home dir (to enable 
the chroot feature of that patch), and try again:

debug1: SELinux support enabled
ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: 
security_getenforce() failed

    I do not understand why using (or not using) a chroot'd directory 
can cause SELinux support to become either "enabled" or "disabled".  I 
thought that SELinux was only a compile-time option, not a runtime 
option...?  (Obviously, I compiled with SELinux support.  I compiled 
from the default Ubuntu package 
openssh-server_4.7p1-8ubuntu1.2_i386.deb, with just the one chroot patch 
applied.)  I thought that perhaps the chroot is preventing sshd from 
finding the sshd_config file, thus causing a runtime option to default 
back to "SELinux support enabled", but the sshd_config does not say 
anything about SELinux:

root at cst2:/etc/ssh# grep -i selinux *
root at cst2:/etc/ssh#

    This observation also concurs with Alexandre's report, because he 
said this failure is only for "accounts where the new ChrootDirectory 
option is active".

    I know C and I'd be happy to work on a fix, but I haven't coded with 
SELinux before, so I'd prefer to have an SELinux expert take a look at 
this.  After all, it's security-related code that I don't fully 
understand...   :)


_    /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 fact that the new ChrootDirectory requires me to set some 
/other/, not-related-to-a-user's-home directory as the "file sharing" 
top-level directory, and furthermore, that the directory must be owned 
by root (and not the user who is logging in), makes it useless for me.  
It doesn't integrate with any of the other applications that support 
per-user files sitting in $HOME.  Other users made this same complaint 
in Feb. when ChrootDirectory was announced, and I did not see a solution 
posted.  (The best answer I saw was from jirib, who tried out the 
feature and then suggested changing all of the user's home directories 
to go under ChrootDirectory.  That is not a workable solution for me.  
See http://undeadly.org/cgi?action=article&sid=20080220110039&pid=28 )

    As a contrasting example, consider the patch mentioned above.  It 
has been used (in the wild) since OpenSSH version 3.2.2.  It chroot's a 
user's home at whatever directory level you specify, using a special 
"/./" flag.  It's also supported natively by ISPConfig, an Open Source 
web hosting management tool (similar to cPanel).  It would be far more 
useful for me if that 3rd-party patch were shipped with OpenSSH as a 
compile-time option.  The ChrootDirectory feature can be dropped, from 
where I'm standing.

    Have I misunderstood the ChrootDirectory option?


Thank you,
Derek Simkowiak