Red Hat Bugzilla – Bug 729648
In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories.
Last modified: 2012-03-14 09:05:52 EDT
I need to update policy and a new sshd_sftpd_t domain type because of these changes in openssh package.
Actually, the concept is wrong.
we need to talk on irc with Dan. Are you ok either later today or tomorrow?
Yes lets discuss the best solution for this. It might be to finally break sshd into two labels, one that listens on the network and one that can manipulate the users directory.
(In reply to comment #2)
> Actually, the concept is wrong.
> we need to talk on irc with Dan. Are you ok either later today or tomorrow?
Ok ping me when.
Ok, could we discuss it tomorrow? We are back from PTO.
With this policy
role system_r types sshd_sftpd_t;
allow sshd_t sshd_sftpd_t:process setexec;
allow sshd_t sshd_sftpd_t:process dyntransition;
we have the following situation:
# ssh mgrepl@localhost
you will end up within sshd_sftpd_t domain.
#Subsystem sftp /usr/libexec/openssh/sftp-server
domtrans_pattern(unpriv_userdomain, sftpd_exec_t, sftpd_t)
# sftp mgrepl@localhost
I am able to end up within sftpd_t
# staff_u:staff_r:sftpd_t:s0 27520 ? 00:00:00 sftp-server
# Subsystem sftp internal-sftp
You will end up
# staff_u:staff_r:staff_t:s0 27663 pts/2 00:00:00 sftp
It means, you set the "sshd_sftpd_t" label as starting context. So you don't have the difference between ssh and sftp.
I guess the problem why we end up within userdomain is the following rule
"sh -c command" is used in openssh.
how is exactly invoked internal-sftpd?
sh -c /path/to/sftpd
I can change it to the direct exec if you wish.
(In reply to comment #10)
> sh -c /path/to/sftpd
> I can change it to the direct exec if you wish.
I thought there is a difference between internal and external?
yes there is difference internal runs with context changed to sftp_sshd_t
and external get his context during exec
Jan yes do direct exec.
After long discussion on the list I think we need to do the following.
We have three different situations.
pam_stack is called and will setexeccon()
setexeccon(NULL) # Clear execcon
# In either case where you do internal-sftp or login start a user shell, the context will run chroot_user_t, which will be allowed to read/write/exec all user content.
exech(sh) # In which case SELinux will perform the original transition to user type setup in pam
In the case where we are not doing chroot the exec of the shell will work correctly as it always has.
Miroslav has to write a policy type for chroot_user_t;
With a new openssh package:
1. I use chroot together with internal-sftp
# sftp test@RHEL6
# ps -efZ |grep sftp
unconfined_u:system_r:chroot_user_t:s0-s0:c0.c1023 test 484 483 0 10:40 ? 00:00:00 sshd: test@internal-sftp
So it looks good.
2. ssh mgrepl@RHEL6
# ps -efZ |grep ssh
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 332 1 0 10:32 ? 00:00:00 /usr/sbin/sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 489 332 1 10:42 ? 00:00:00 sshd: mgrepl [priv]
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 mgrepl 493 489 0 10:42 ? 00:00:00 sshd: mgrepl@pts/0
# id -Z
3. I enabled internal-sftp without chroot and we have issue
#============= sshd_t ==============
#!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work.
allow sshd_t staff_t:process dyntransition;
Fixed in selinux-policy-3.7.19-109.el6
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.