SSHFS (SELinux) frustrations

[Mr Dash Four]

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-sf... 
(Secure chroot() remote file access via SFTP and SSH)

[Mr Dash Four]

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

[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(a)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

[Mr Dash Four]

>  Also I am going to write a blog how to setup sftp/chroot/SELinux 
>  solution which could help you with this issue. 
That would be good, even if I use
this just to confirm that what I did 
was correct - at least it would help others with similar issues.

The way I implemented this now works without further hitches, but it was 
a bit tricky, particularly with enabling (and redirecting) the syslog 
inside the chroot. The source of information I quoted in my initial post 
is a good one, though it doesn't account for SELinux and this in itself 
is enough to prevent it working if further adjustments to the SELinux 
policy are not done.