FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 01-11-2012, 02:45 PM
Mr Dash Four
 
Default SSHFS (SELinux) frustrations

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_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/home(/.*)?
gen_context(system_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/dev -d
gen_context(system_ubject_r:device_t,s0)
/home/sftp-chroot/dev/log -s
gen_context(system_ubject_r:devlog_t,mls_systemh igh)


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_ubject_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)

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-16-2012, 06:43 PM
Mr Dash Four
 
Default SSHFS (SELinux) frustrations

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_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/home(/.*)?
gen_context(system_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/dev -d
gen_context(system_ubject_r:device_t,s0)
/home/sftp-chroot/dev/log -s
gen_context(system_ubject_r:devlog_t,mls_systemh igh)


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_ubject_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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-17-2012, 07:11 AM
Miroslav Grepl
 
Default SSHFS (SELinux) frustrations

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_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/home(/.*)?
gen_context(system_ubject_r:user_home_dir_t,s0)
/home/sftp-chroot/dev -d
gen_context(system_ubject_r:device_t,s0)
/home/sftp-chroot/dev/log -s
gen_context(system_ubject_r:devlog_t,mls_systemh igh)


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_ubject_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@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
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-17-2012, 11:41 AM
Mr Dash Four
 
Default SSHFS (SELinux) frustrations

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.


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 09:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org