SSHFS (SELinux) frustrations

[Miroslav Grepl]

On 01/16/2012 08:43 PM, Mr Dash Four wrote:
>
>> 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)
> I fixed this over the weekend, but thought to post a brief note of my 
> solution here for posterity just in case someone else stumbles across 
> the same problem.
>
> As is usually the case with SELinux, I went for the "sledge-hammer" 
> solution after spending quite a number of hours banging my head 
> against the wall - I defined my own type (sshfs_root_t in my case) and 
> also constructed a separate pair of .te & .fc files responsible for 
> SSHFS implementation - sshfs.te & sshfs.fc. In the .fc file I defined 
> the context of the sshfs chroot system to be assigned to my 
> newly-created type - "/home/sftp-chroot(/.*)?". In sshfs.te I used the 
> manage_{dirs,files,sock_files,lnk_files}_pattern macros as well as 
> filetrans_pattern define from file_patterns.spt to grant the 
> appropriate level of access for this new context to the sftp_t and 
> sshd_t types.
>
> It was also necessary to grant similar access for the new context to 
> syslogd_t in order to enable proper login inside the chroot. After 
> including this in my new policy all is well and everything works as it 
> should!
>
> Admittedly, I could have used various tunables present in both ssh.te 
> and ftp.te policies to grant the appropriate access to 
> "user_home_dir_t" as was my initial intention, but this was giving a 
> wider-than-intended access to *all* directories defined by that 
> context - something I was not very happy with, hence I went for the 
> newly-defined context instead, so that I could limit the directories 
> as well as the domains to which to grant such access.
>
> -- 
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
The problem is "sftp/chroot/SELinux" implementation is not working 
correctly on F15. We added fixes to RHEL6/Rawhide which are going to be 
backported. Also I am going to write a blog how to setup 
sftp/chroot/SELinux solution which could help you with this issue.

Regards,
Miroslav