SSHFS (SELinux) frustrations

Mr Dash Four mr.dash.four at googlemail.com
Wed Jan 11 15:45:07 UTC 2012


I am trying to implement SSH FS on a shared DMZ box running SELinux (the 
latest policy in FC15) and have the layout almost a carbon copy of what 
is described in [1]. I have been frustrated by multiple failures, however.

The first thing I did after creating the directories is to set the 
SELinux domain on these:

/home/sftp-chroot        -d    
gen_context(system_u:object_r:user_home_dir_t,s0)
/home/sftp-chroot/home(/.*)?        
gen_context(system_u:object_r:user_home_dir_t,s0)
/home/sftp-chroot/dev            -d    
gen_context(system_u:object_r:device_t,s0)
/home/sftp-chroot/dev/log    -s    
gen_context(system_u:object_r:devlog_t,mls_systemhigh)

I've also altered the rsyslog in the way described in [1] so that a log 
socket can be used inside chroot. I also altered the policy to enable 
ssh home dirs access - gen_tunable(sftpd_enable_homedirs, true) in 
ftp.te. On a side note, is there a way to do that in my policy 
(sftpd_enable_homedirs -> on), without either altering ftp.te or using 
setsebool? I've also noticed that /usr/libexec/openssh/sftp-server has 
"bin_t" type - shouldn't that be "sftpd_t"?

When I try to use SSHFS with a dedicated using user account I used to 
get a lot of AVC's, but I eventually got them reduced to just 2 - one 
known (below), and one unknown:

type=AVC msg=audit(1326034699.037:356): avc:  denied  { create } for  
pid=2713 comm="sshd" name="ltm-0.42.0.tar.bz2" 
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1326034699.037:356): arch=40000003 syscall=5 
success=no exit=-13 a0=241388 a1=80c1 a2=81b4 a3=233284 items=0 
ppid=2710 pid=2713 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=30 comm="sshd" exe="/usr/sbin/sshd" 
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

This happens when I try to copy a single file (ltm-0.42.0.tar.bz2 in 
this case) to the SSHFS partition. So, in effect, even though I can look 
at my newly-shared partition I can't do anything with it because of 
SELinux. If I go into permisive mode - everything is fine (though I get 
a lot of avcs, but that's to be expected).

The other error I get is when rsyslogd starts (at the very beginning 
when the DMZ box starts) - I get "Permission denied" message and 
rsyslogd cannot open that socket in /home/sftp-chroot/dev/log for some 
reason - don't know why as it appears the context is properly set there!

Any help?

[1] - 
http://blog.famzah.net/2011/02/03/secure-chroot-remote-file-access-via-sftp-and-ssh/ 
(Secure chroot() remote file access via SFTP and SSH)


More information about the selinux mailing list