I'm trying to setup an SFTP "drop box" for a number of users to upload/share files to a central repository, without them being able to see the rest of the system in any way. OpenSSH supports this through ChrootDirectory. In addition, by using "ForceCommand internal-sftp", the chroot directory doesn't need to contain anything. (no /bin/bash, no libraries etc). I've used the following configuration in /etc/ssh/sshd_config: Match Group chroot ChrootDirectory /home/ssh-chroot/ ForceCommand internal-sftp I have a user in supplemental group "chroot", home dir /home/user, shell /bin/false and ssh keys. Using WinSCP (since my clients will be Windows based), I'm able to connect using keys, and get dropped into /home/ssh-chroot/. # ls -Zlad /home/ssh-chroot/ /home/ssh-chroot/upload/ drwxr-xr-x. 3 system_u:object_r:user_home_dir_t:s0 root root 4096 2010-02-04 14:36 /home/ssh-chroot/ drwxrwx---. 2 unconfined_u:object_r:user_home_t:s0 root chroot 4096 2010-02-04 14:58 /home/ssh-chroot/upload/ # ps Zauxf unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 13677 0.0 0.0 11472 2912 ? Ss 14:55 0:00 sshd: user [priv] unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 user 13680 0.0 0.0 11472 1668 ? S 14:55 0:00 \_ sshd: user@notty unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 user 13681 0.0 0.0 11624 1396 ? Ss 14:55 0:00 \_ sshd: user@internal-sftp-server In throry, my user should be able to write to /home/ssh-chroot/upload/. I practice the user sees a "permission denied", and I get the following audit log entry: type=AVC msg=audit(1265295095.883:31053): avc: denied { write } for pid=13267 comm="sshd" name="upload" dev=dm-2 ino=6553602 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir Of course, "setenforce 0" allows this to work with no issues, although other avc messages are seen relating to this (add_name, create, write for the actual file).
Mark, Could you give me some information ? # rpm -qa selinux-policy\* Is there anything in the /var/log/secure ? # grep setcon /var/log/secure
selinux-policy-3.6.32-78.fc12.noarch selinux-policy-targeted-3.6.32-78.fc12.noarch Nothing in /var/log/secure
We have been talking about that with Mark and now I am trying to reproduce it.
Mark, could you try to install selinux-policy-3.6.32-85.fc12.noarch.rpm selinux-policy-targeted-3.6.32-85.fc12.noarch.rpm packages from koji. http://koji.fedoraproject.org/koji/buildinfo?buildID=154841
Same issues: # rpm -q selinux-policy selinux-policy-targeted selinux-policy-3.6.32-85.fc12.noarch selinux-policy-targeted-3.6.32-85.fc12.noarch type=AVC msg=audit(1265646794.315:32282): avc: denied { write } for pid=5172 comm="sshd" name="upload" dev=dm-2 ino=6553602 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir type=SYSCALL msg=audit(1265646794.315:32282): arch=40000003 syscall=5 success=no exit=-13 a0=27a53f8 a1=82c1 a2=1b6 a3=d5ab14 items=0 ppid=5171 pid=5172 auid=502 uid=502 gid=504 euid=502 suid=502 fsuid=502 egid=504 sgid=504 fsgid=504 tty=(none) ses=305 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
ping, is there still someone alive?
Yes?
Miroslav, what is the progress?
Unfortunately I am not able to reproduce it. There was a lot of policy updates. Mark, are you still seeing this issue?
Yes I am. I'm using Fedora 13 now with openssh-server-5.4p1-3.fc13.x86_64 The following is how I'm testing: # groupadd chroot # useradd -G chroot -s /bin/false test_ssh # mkdir -p /home/ssh-chroot/upload # chmod g+w /home/ssh-chroot/upload # chown root.chroot /home/ssh-chroot/upload # chcon unconfined_u:object_r:user_home_t:s0 /home/ssh-chroot/upload # chcon unconfined_u:object_r:user_home_dir_t:s0 /home/ssh-chroot Create SSH keys on windows box and add them to /home/test_ssh/.ssh/authorized_keys Add the following to /etc/ssh/sshd_config: Subsystem sftp internal-sftp Match Group chroot ChrootDirectory /home/ssh-chroot/ ForceCommand internal-sftp At this point the test_ssh user can login the server using WinSCP and gets dropped into /home/ssh-chroot/ from where it can progress into /home/ssh-chroot/upload. Any attempt to write a file to this directory gets the following AVC denial: type=AVC msg=audit(1284626238.008:30187): avc: denied { write } for pid=27870 comm="sshd" name="upload" dev=dm-6 ino=1572866 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
Mark, thanks for steps to reproduce. Now I am able to reproduce it.
Jan, could it be a problem with "ChrootDirectory"? "dyntrasition" from sshd to sftpd doesn't happen in this case. # sftp test_ssh@localhost # ps -eZ | grep sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26910 ? 00:00:00 sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26914 ? 00:00:00 sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26915 ? 00:00:00 sshd without using chroot # sftp mgrepl@localhost # ps -eZ | grep sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26920 ? 00:00:00 sshd unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26925 ? 00:00:00 sshd unconfined_u:system_r:sftpd_t:s0-s0:c0.c1023 26926 ? 00:00:00 sshd
Works for me. Appended to /etc/ssh/sshd_config: Match Group sftponly X11Forwarding no AllowTcpForwarding no ChrootDirectory /home/%u ForceCommand internal-sftp # ls -laZ /home/foo/ drwxr-xr-x. root root unconfined_u:object_r:user_home_dir_t:s0 . drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .. drwxr-xr-x. root root unconfined_u:object_r:user_home_t:s0 bar drwx------. foo foo unconfined_u:object_r:ssh_home_t:s0 .ssh [root@paja foo]# ls -lZ /home/foo/.ssh/ -rw-------. foo foo unconfined_u:object_r:ssh_home_t:s0 authorized_keys [root@paja foo]# ls -lZ /home/foo/bar/ -rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 test.txt # rpm -qa selinux-policy\* selinux-policy-targeted-3.7.19-65.fc13.noarch selinux-policy-3.7.19-65.fc13.noarch However I couldn't get the write access to work: sftp> ls bar/ bar/test.txt sftp> get bar/test.txt Fetching /bar/test.txt to test.txt sftp> cd bar sftp> put test.txt Uploading test.txt to /bar/test.txt remote open("/bar/test.txt"): Permission denied Sealert: Source Context unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects test.txt [ file ] Source sshd Source Path /usr/sbin/sshd Source RPM Packages openssh-server-5.4p1-3.fc13 Policy RPM selinux-policy-3.7.19-65.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall_boolean Platform Linux 2.6.34.7-61.fc13.x86_64 #1 SMP Tue Oct 19 04:06:30 UTC 2010 x86_64 x86_64 Raw Audit Messages node= type=AVC msg=audit(1287918783.147:16868): avc: denied { write } for pid=2698 comm="sshd" name="test.txt" dev=dm-1 ino=21 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file node= type=SYSCALL msg=audit(1287918783.147:16868): arch=c000003e syscall=2 success=no exit=-13 a0=7f9993353fc0 a1=241 a2=1a4 a3=e items=0 ppid=2697 pid=2698 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=25 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) Should I open a new issue for getting the write access fixed?
Well my original report was exactly about write access, so I'd say no :) Logging in while using ChrootDirectory has never been at issue; writing to files was the problem. As an aside, I'm using an older openssh-server-5.1p1 on CentOS 5.5 to enable ChrootDirectory as well as the internal-sftp server, and that has no issues with writing to files... Probably a different SELinux policy?
Any progress here?
None recently. I see Miroslav was able to reproduce it, followed by another report for the same issue so I suspect it's still on Miroslav's pile.
(In reply to comment #12) > Jan, > could it be a problem with "ChrootDirectory"? > > "dyntrasition" from sshd to sftpd doesn't happen in this case. > > # sftp test_ssh@localhost > # ps -eZ | grep sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26910 ? 00:00:00 sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26914 ? 00:00:00 sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26915 ? 00:00:00 sshd > > without using chroot > > # sftp mgrepl@localhost > # ps -eZ | grep sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26920 ? 00:00:00 sshd > unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26925 ? 00:00:00 sshd > unconfined_u:system_r:sftpd_t:s0-s0:c0.c1023 26926 ? 00:00:00 sshd Jan, look at this my question.
from the spec changelog: * Fri Jul 17 2009 Jan F. Chadima <jchadima> - 5.2p1-14 - changed internal-sftp context to sftpd_t the piece of the code: } else if (s->is_subsystem == SUBSYSTEM_INT_SFTP) { extern int optind, optreset; int i; char *p, *args; setproctitle("%s@%s", s->pw->pw_name, INTERNAL_SFTP_NAME); args = xstrdup(command ? command : "sftp-server"); for (i = 0, (p = strtok(args, " ")); p; (p = strtok(NULL, " "))) if (i < ARGV_MAX - 1) argv[i++] = p; argv[i] = NULL; optind = optreset = 1; __progname = argv[0]; #ifdef WITH_SELINUX ssh_selinux_change_context("sftpd_t"); #endif exit(sftp_server_main(i, argv, s->pw));
Jan, from my point of you an issue is caused by Match Group sftponly X11Forwarding no AllowTcpForwarding no ChrootDirectory /home/%u ForceCommand internal-sftp when internal-sftp is not running in the proper domain == sftpd_t. If you just use Subsystem sftp internal-sftp then it works.
This bug is also affecting RHEL6. unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 test 2047 0.0 0.0 95384 1596 ? SNs 08:22 0:00 \_ sshd: test@internal-sftp Confirming that internal-sftp is running as unconfined_u:system_r:sshd_t:s0 instead of sftp so the following sebools have no affect: # getsebool -a | grep sftp sftpd_anon_write --> off sftpd_enable_homedirs --> on sftpd_full_access --> off sftpd_write_ssh_home --> on without selinux everthing works superb. Running openssh-5.3p1-20.el6.x86_64. Any help/escalation would be appreciated.
I am not fluent enough in SELinux to decipher the difference here: Not using chroot, still using internal-sftp type=LOGIN msg=audit(1299576444.277:287): login pid=2133 uid=0 old auid=501 new auid=500 old ses=28 new ses=36 type=USER_ROLE_CHANGE msg=audit(1299576444.326:288): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed' type=USER_ROLE_CHANGE msg=audit(1299576444.328:289): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1299576444.349:290): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success' Using chroot with internal-sftp: type=LOGIN msg=audit(1299577358.024:337): login pid=2263 uid=0 old auid=501 new auid=500 old ses=28 new ses=41 type=USER_ROLE_CHANGE msg=audit(1299577358.070:338): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed' type=USER_ROLE_CHANGE msg=audit(1299577358.071:339): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1299577358.101:340): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success' type=CRED_ACQ msg=audit(1299577358.105:341): user pid=2267 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success' type=AVC msg=audit(1299577363.793:342): avc: denied { write } for pid=2268 comm="sshd" name="test.txt" dev=dm-2 ino=1310727 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1299577363.793:342): arch=c000003e syscall=2 success=yes exit=5 a0=7fd1d2b21100 a1=241 a2=1b6 a3=11 items=0 ppid=2267 pid=2268 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=41 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) I was able to work around the problem by mount -o bind /proc /chroot/proc... But that doesn't seem very secure.
(In reply to comment #21) > I am not fluent enough in SELinux to decipher the difference here: > > Not using chroot, still using internal-sftp So without chroot option it works also for you and you should see sshd running as sftpd_t as I wrote in the comment 17. Can you confirm it?
Confirmed; that was my understanding. Note the last line; chroot works with internal-sftp if I mount /proc inside the chroot. Selinux or openssh seems to be reading the attr file out of the proc directory which it can't find if its chrooted
(In reply to comment #23) > Confirmed; that was my understanding. Note the last line; chroot works with > internal-sftp if I mount /proc inside the chroot. Selinux or openssh seems to > be reading the attr file out of the proc directory which it can't find if its > chrooted can you post strace please?
SELinux is going to read /proc/filesystem to figure out if SELinux is enabled. It needs /proc and /selinux in order to work properly.
experimentally solved in rawhide's openssh-5.8p1-18 please test
(In reply to comment #26) > experimentally solved in rawhide's openssh-5.8p1-18 please test Great, I am going to test it.
I'm having the same issue with RHEL6. Is there going to be a rpm released to fix this issue? Or am I going to have to patch this openssh-5.8p2 manually as I have done in my test environment?
(In reply to comment #28) > I'm having the same issue with RHEL6. Is there going to be a rpm released to > fix this issue? Or am I going to have to patch this openssh-5.8p2 manually as I > have done in my test environment? the best way is to contact RH SUPPORT.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Given the automated warning above, could someone change the OS to RHEL 6 or 6.1 to keep the bug report alive? This is also an issue in RHEL 6.1, openssh-server-5.3p1-52: $ sftp username@server Connecting to server... username@server's password: sftp> ls Couldn't get handle: Permission denied sftp> ls Couldn't get handle: Permission denied sftp> cd web sftp> put foo.txt Uploading foo.txt to /web/foo.txt Couldn't get handle: Permission denied
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.