OpenSSH + chroot + SELinux = broke
dereks at realloc.net
Mon May 26 06:35:58 EST 2008
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:
Alexandre described an SELinux failure with the following error message:
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:
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
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
_ /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?
More information about the openssh-unix-dev