Hide Forgot
Description of problem: In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories. Issue in detail : When chrooted users trying upload files to their home directory, selinux deny it with the following logs : type=AVC msg=audit(1299680139.405:61165): avc: denied { write } for pid=3906 comm="sshd" name="outbound" dev=dm-2 ino=12845071 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir Version-Release number of selected component (if applicable): RHEL6 selinux-policy-3.7.19-54.el6 How reproducible: Steps to Reproduce: 1. setup chrooted sftp: sshd_config : ChrootDirectory /home/%u Subsystem sftp internal-sftp 2. Try to upload a new file to user's home directory. Actual results: selinux deny it. Expected results: selinux should't deny it (?). Additional info: RHEL6 (even rhel5) selinux policy doesn't allow sshd_t to write to a directory which has the context user_home_t.So the above denial is expected. allow sshd_t user_home_t : dir { ioctl read getattr lock search open } ; Also there is no SELinux booleans which allow this access. Note: -On RHEL5, this is not an issue since in RHEL5 we allow the sshd to be unconfined so it can transition to the unconfined_t domain. -on RHEL6, sshd run in sshd_t which is not unconfined and thus we see the issue here. -on RHEL6, issue is not seen when the default subsystem is used, ie /usr/libexec/openssh/sftp-server. This subsystem runs in in 'unconfined_t' context which has access to almost all objects. So the transfer should work fine. but this can't be used for chrooting. Question: - Apart from writing a custom policy, What the best way to deal this situation ?. - This could be treated as bug ?. If allowing such access is considered as security risk, we may need a boolean to allow this ?. Most of the users doesn't like to keep their own policy files.
Miroslav I thought we had some fixes for chroot and sshd?
Unfortunately ... the same issue as #561881.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
*** Bug 715338 has been marked as a duplicate of this bug. ***
Hi I wrote a reproducer, though I still cannot write to user_home_dir_t directory with the latest openssh package: time->Wed Aug 3 12:01:14 2011 type=SYSCALL msg=audit(1312387274.711:142887): arch=c000003e syscall=2 success=no exit=-13 a0=7f36ec2b6470 a1=241 a2=180 a3=13 items=0 ppid=29037 pid=29038 auid=511 uid=511 gid=512 euid=511 suid=511 fsuid=511 egid=512 sgid=512 fsgid=512 tty=(none) ses=12429 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312387274.711:142887): avc: denied { create } for pid=29038 comm="sshd" name="test" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file # rpm -q openssh openssh-5.3p1-63.el6.x86_64 Seems to me that sshd is still not running internal-sftp with correct context. Mirek pls did you test the latest fix?
Why would sshd be creating a file test in the users homedir?
Internal sftp is still sshd, but wit another context. It should have the r/w permissions to the homedir.
I see the same issue, this works in Fedora.
I see this error: ssh_selinux_change_context: setcon unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 from unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 failed with Invalid argument Can someone from selinux explain why is this prohibited?
"sshd_sftpd_t" does not exist. Miroslav V. has a test policy which we created.
The test policy is insufficient. It even breaks regular login.
When I try to login via ssh I get these AVC's, should I add them to the policy module? Why we have sshd_sftpd_t denials when I'm not connecting via sftp? type=AVC msg=audit(1312471372.239:144551): avc: denied { search } for pid=27258 comm="sshd" name="root" dev=dm-0 ino=3014657 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir type=SYSCALL msg=audit(1312471372.239:144551): arch=c000003e syscall=4 success=no exit=-13 a0=7fffb9b35f80 a1=7fffb9b35ef0 a2=7fffb9b35ef0 a3=fffffffb items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312471372.240:144552): avc: denied { search } for pid=27258 comm="sshd" name="root" dev=dm-0 ino=3014657 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir type=SYSCALL msg=audit(1312471372.240:144552): arch=c000003e syscall=80 success=no exit=-13 a0=7f2b07a06660 a1=7f2b06c298b8 a2=9 a3=0 items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312471372.240:144553): avc: denied { write } for pid=27258 comm="sshd" path="/dev/pts/1" dev=devpts ino=4 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=SYSCALL msg=audit(1312471372.240:144553): arch=c000003e syscall=1 success=no exit=-13 a0=2 a1=7fffb9b337a0 a2=3b a3=ffffffff items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312471372.241:144554): avc: denied { execute } for pid=27258 comm="sshd" name="bash" dev=dm-0 ino=524336 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=SYSCALL msg=audit(1312471372.241:144554): arch=c000003e syscall=59 success=no exit=-13 a0=7f2b07a06680 a1=7fffb9b361a0 a2=7f2b079fce70 a3=0 items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312471372.241:144555): avc: denied { write } for pid=27258 comm="sshd" path="/dev/pts/1" dev=devpts ino=4 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=SYSCALL msg=audit(1312471372.241:144555): arch=c000003e syscall=1 success=no exit=-13 a0=2 a1=7fffb9b33370 a2=1d a3=ffffffef items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1312471372.243:144556): avc: denied { sigchld } for pid=27253 comm="sshd" scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1312471372.243:144556): arch=c000003e syscall=61 success=no exit=-13 a0=ffffffffffffffff a1=7fffb9b3671c a2=1 a3=0 items=0 ppid=27226 pid=27253 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
Yes add it. The sshd_sftp_t is a context compatibnle with both partially sshd and sftp. It is used as intermediate (pty alocation) in sshd in case of ssh. It is used as sftpd in case of sftp.
Well, but the problem is you end up in sshd_t domain if you only use Subsystem internal-sftp definition. But you should end up in sftpd_t domain. Miroslav, does it work in permissive mode?
This is technically impossible. The decision ssh/sftp is much more later than the last ability to change context. The server does not know if client will ask for ssh or sftp (and theoretically may ask both in different channels) in the time of context change, The context sshd_sftp_t should allow pty allocation as well full home access.
I think ON_QA state of this bug is misleading. We still don't know what the fix will be here exactly
Moving to ASSIGNED. This bug will need more discussion between the developers to find a proper solution. The current solution doesn't pass testing, thus ON_QA state is clearly wrong.
Code changed according to Dan Walsh's proposal.
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. http://rhn.redhat.com/errata/RHBA-2011-1551.html