Description of problem: Using OpenSSH chroot shell functionality the sshd process attempts a process transition from "chroot_user_t" to "unconfined_t" when launching the user shell (in this case "/bin/bash -r") and is denied, which disconnects the SSH session shortly after authentication. This OpenSSH session disconnection behaviour also appears to occur in FC16. Under FC15 i386 PAE the OpenSSH chroot ran as "sshd_t" and SELinux did not deny the process transition to "unconfined_t" when launching a chroot shell. FC17 i386 PAE ps dump (captured with SELinux in Permissive mode): system_u:system_r:sshd_t:s0-s0:c0.c1023 1143 2277 2277 2277 ? -1 Ss 0 0:00 \_ sshd: testuser [priv] system_u:system_r:chroot_user_t:s0-s0:c0.c1023 2277 2280 2277 2277 ? -1 S 1001 0:00 \_ sshd: testuser@pts/3 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2280 2281 2281 2281 pts/3 2281 Ss+ 1001 0:00 \_ /bin/bash -r FC15 i386 PAE ps dump (captured with SELinux in Enforcing mode): system_u:system_r:sshd_t:s0-s0:c0.c1023 27438 3789 3789 3789 ? -1 Ss 0 0:00 \_ sshd: testuser [priv] system_u:system_r:sshd_t:s0-s0:c0.c1023 3789 3792 3789 3789 ? -1 S 503 0:00 \_ sshd: testuser@pts/2 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3792 3793 3793 3793 /chroot/dev/pts/2 3793 Ss+ 503 0:00 \_ /bin/bash -r There are a number of other SELinux restrictions on "chroot_user_t" that prevent OpenSSH chroot from working for which audit2allow can create "allow" policy modules, but the policies will still not allow the process transition once the SELinux module is installed. module fc17sshchroot 1.0; require { type ptmx_t; type user_devpts_t; type chroot_user_t; type devpts_t; type shell_exec_t; type unconfined_t; class file execute; class dir search; class unix_dgram_socket { create connect }; class chr_file { read write ioctl getattr }; class process transition; class file { read open }; } #============= chroot_user_t ============== allow chroot_user_t ptmx_t:chr_file { read write ioctl }; allow chroot_user_t self:unix_dgram_socket { create connect }; allow chroot_user_t user_devpts_t:chr_file { read write ioctl getattr }; allow chroot_user_t devpts_t:dir search; allow chroot_user_t shell_exec_t:file { read open execute }; #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Constraint rule: allow chroot_user_t unconfined_t:process transition; Version-Release number of selected component (if applicable): openssh-server-5.9p1-22.fc17.i686 bash-4.2.28-1.fc17.i686 kernel-PAE-3.4.0-1.fc17.i686 selinux-policy-3.10.0-128.fc17.noarch selinux-policy-targeted-3.10.0-128.fc17.noarch selinux-policy-devel-3.10.0-128.fc17.noarch How reproducible: Setup OpenSSH for chroot environment and create the required chroot tree for chroot shell users. In this case, the chroot part of the sshd_config is: Match Group sshjail ChrootDirectory /chroot X11Forwarding no AllowTcpForwarding yes Banner /chroot/etc/sshjailmsg ForceCommand /bin/bash -r OpenSSH setup for key authentication (PasswordAuthentication off). Steps to Reproduce: 1. Add a user to a group that OpenSSH will force to chroot (e.g. sshjail) 2. Connect to SSH with target user and authenticate using key 3. SSH session will disconnect and the following avc denied entry will be recorded: type=AVC msg=audit(1339167129.184:1339): avc: denied { transition } for pid=2281 comm="sshd" path="/bin/bash" dev="dm-1" ino=522245 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process Actual results: SSH session disconnects after authentication due to SELinux denial Expected results: SSH shell spawns and user has a chroot SSH shell Additional info: related ssh sebools in FC17: ssh_chroot_rw_homedirs --> off ssh_sysadm_login --> off Turning either or both of these booleans to "on" does not resolve the issue
We do not want ssh_chroot_t to transition to unconfined_t at all. ssh guys could this be related to the privsep patch?
The transition is probably done by pam_selinux module which sets context for next executed shell. Maybe ssh_selinux_change_context() should clean SELinux exec context after SELinux context change. Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Open Session Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Username= test SELinux User = unconfined_u Level= s0-s0:c0.c1023 Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Selected Security Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Checking if unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 mls range valid for unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): set test security context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): set test key creation context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Jun 11 16:34:48 f17-openssh sshd[4347]: pam_unix(sshd:session): session opened for user test by (uid=0) Jun 11 16:34:48 f17-openssh sshd[4347]: User child is on pid 4351 Jun 11 16:34:48 f17-openssh sshd[4351]: debug1: PAM: establishing credentials Jun 11 16:34:48 f17-openssh sshd[4351]: debug3: ssh_selinux_setup_variables: setting execution context Jun 11 16:34:48 f17-openssh sshd[4351]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:chroot_user_t:s0-s0:c0.c1023'
Yes do a setexeccon(NULL) Will clear the context.
I realized that simply adding setexeccon() won't help. All chroot users are run with chroot_user_t, but this context is supposed to be used only for internal-sftp. chroot_user_t process can't exec bash, use char files and so. I believe that since we have privsep patch we don't need chroot_user_t anymore - all unprivileged sshd child processes included internal-sftp are run with user's context so there's no need to change their context to chroot_user_t if they are chrooted.
(In reply to comment #4) > I realized that simply adding setexeccon() won't help. All chroot users are > run > with chroot_user_t, but this context is supposed to be used only for > internal-sftp. chroot_user_t process can't exec bash, use char files > and so. > > I believe that since we have privsep patch we don't need chroot_user_t > anymore - all unprivileged sshd child processes included internal-sftp > are run with user's context so there's no need to change their context > to chroot_user_t if they are chrooted. Sounds as good idea. If I remember correctly, we wanted to get out at least this users stuff (interlnal-sftp) from sshd_t label. It was first step. But now we have working privsep patch which makes me to agree with you.
But if the user runs with unconfined_t, we loose any lock down. If you are saying we will recommend that the chroot_t user run with guest_t then I am fine with it.
Is there a workaround we can use prior to a fix being released? In our particular case it would be better for us to have user processes for restricted users running as "unconfined" in a chroot SSH environment than to turn SELinux off altogether just to get chroot SSH to work. Is there a policy file we can apply or some other temporary measure we can take to get this working for now?
Adam If you want you can add a policy module to make the chroot_user_t an unconfined_domain. Create a file mychrootuser.te with the following content. policy_module(mychrootuser,1.0 gen_require(` type chroot_user_t; ') unconfined_domain(chroot_user_t) Then make the policy file # make -f /usr/share/selinux/devel/include/Makefile # semodule -i mychrootuser.pp
Thanks for the policy module Daniel. I tried to compile it under fc17 i386 PAE and modified it as follows [I believe the ")" was missing on the first line]: --- policy_module(ssh_chroot_workaround,1.0) gen_require(` type chroot_user_t; ') unconfined_domain(chroot_user_t) --- I had to use the Makefile in /usr/share/selinux/devel instead of /usr/share/selinux/devel/include as using the one in the include directory gave the following: make: *** /usr/share/selinux/targeted: Is a directory. Stop. The policy module compiled into a .pp which I then tried to install as follows: --- [<myuser>@<myserver> devel]$ semodule -i ssh_chroot_workaround.pp libsepol.expand_terule_helper: duplicate TE rule for chroot_user_t user_home_dir_t:fifo_file user_home_t libsepol.expand_module: Error during expand libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed! --- I'm not sure what to do about this conflict. FYI the selinux and kernel packages installed are as follows: selinux-policy-devel-3.10.0-134.fc17.noarch libselinux-python-2.1.10-3.fc17.i686 libselinux-2.1.10-3.fc17.i686 selinux-policy-3.10.0-134.fc17.noarch selinux-policy-targeted-3.10.0-134.fc17.noarch libselinux-utils-2.1.10-3.fc17.i686 kernel-PAE-3.4.4-5.fc17.i686
I've finally prepared a test build for Fedora 18 [1] based on the openssh-6.0p1 version and without the chroot_user_t. I'd rather don't add this change to currrent versions given that there are probably some existing configurations depending on chroot_user_t and this update would break behavior. Also I'd propose to note this change in release notes with notice that chroot users shall be set to guest_u as Dan suggested. [1] http://plautrba.fedorapeople.org/openssh/openssh-6.0p1-no-chroot_user_t/
Great. I am willing to test it.
It works and a user has a userdomain instead of chroot_user_t.
openssh-6.1p1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/openssh-6.1p1-1.fc18
Package openssh-6.1p1-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13976/openssh-6.1p1-1.fc18 then log in and leave karma (feedback).
I'm still seeing the user get disconnected when they ssh in with a chroot home directory set. Steps ----- Installed FC18 Alpha x86: [getinfo@fc18alpha ~]# uname -a Linux fc18alpha.pal.internal 3.6.0-0.rc2.git2.1.fc18.i686.PAE #1 SMP Wed Aug 22 11:57:34 UTC 2012 i686 i686 i386 GNU/Linux [getinfo@fc18alpha ~]# rpm -qa | grep ssh openssh-6.1p1-1.fc18.i686 openssh-server-6.1p1-1.fc18.i686 libssh2-1.4.2-2.fc18.i686 openssh-clients-6.1p1-1.fc18.i686 Set testuser to guest_u and verify: [testuser@fc18alpha ~]id -Z guest_u:guest_r:guest_t:s0 Connection attempt sshd LogLevel INFO: Sep 18 18:41:27 fc18alpha sshd[1540]: Accepted publickey for testuser from w.x.y.z port 52416 ssh2 Sep 18 18:41:27 fc18alpha sshd[1540]: pam_unix(sshd:session): session opened for user testuser by (uid=0) Sep 18 18:41:27 fc18alpha sshd[1543]: ssh_selinux_copy_context: getcon failed with No such file or directory Sep 18 18:41:30 fc18alpha sshd[1540]: pam_unix(sshd:session): session closed for user testuser If SELinux is in Enforcing mode the user is disconnected. If in Permissive mode they are not disconnected and can use their ssh chroot shell. From the debug3 logs on a subsequent connection attempt it looks like chroot_user_t is the destination context for the transition: Sep 18 19:04:41 fc18alpha sshd[736]: debug1: matching key found: file /home/testuser/.ssh/authorized_keys, line 1 Sep 18 19:04:41 fc18alpha sshd[736]: Found matching RSA key: <key> Sep 18 19:04:41 fc18alpha sshd[736]: debug1: restore_uid: 0/0 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key 0xb9149650 is allowed Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 22 Sep 18 19:04:41 fc18alpha sshd[736]: debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: Postponed publickey for testuser from w.x.y.z port 52590 ssh2 [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug1: userauth-request for user testuser service ssh-connection method publickey [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug1: attempt 2 failures 0 [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug2: input_userauth_request: try method publickey [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_allowed entering [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 21 [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive_expect entering: type 22 [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 21 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed entering Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key_from_blob: 0xb914dcd8 Sep 18 19:04:41 fc18alpha sshd[736]: debug1: temporarily_use_uid: 1001/1001 (e=0/0) Sep 18 19:04:41 fc18alpha sshd[736]: debug1: trying public key file /home/testuser/.ssh/authorized_keys Sep 18 19:04:41 fc18alpha sshd[736]: debug1: fd 4 clearing O_NONBLOCK Sep 18 19:04:41 fc18alpha sshd[736]: debug1: matching key found: file /home/testuser/.ssh/authorized_keys, line 1 Sep 18 19:04:41 fc18alpha sshd[736]: Found matching RSA key: <key> Sep 18 19:04:41 fc18alpha sshd[736]: debug1: restore_uid: 0/0 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key 0xb914dcd8 is allowed Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 22 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_verify entering [preauth] Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 23 [preauth] Sep 18 19:04:41 fc18alpha sshd[739]: debug1: PAM: establishing credentials Sep 18 19:04:41 fc18alpha sshd[739]: debug3: ssh_selinux_setup_variables: setting execution context Sep 18 19:04:41 fc18alpha sshd[739]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:chroot_user_t:s0-s0:c0.c1023' Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 61 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_audit_event entering Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 73 Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_term: tearing down sessions Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: cleanup Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: closing session Sep 18 19:04:41 fc18alpha sshd[736]: pam_unix(sshd:session): session closed for user testuser Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: deleting credentials Sep 18 19:04:59 fc18alpha sshd[735]: Received signal 15; terminating. Are there more SELinux settings for me to set?
For the sake of completeness, here are the selinux packages. Note that I updated the openssh packages after the install of FC18 Alpha, I just neglected to state so explicitly in my last comment: [testuser@fc18alpha ~]# rpm -qa | grep selinux libselinux-2.1.11-6.fc18.i686 selinux-policy-devel-3.11.1-21.fc18.noarch libselinux-python-2.1.11-6.fc18.i686 selinux-policy-targeted-3.11.1-21.fc18.noarch libselinux-utils-2.1.11-6.fc18.i686 selinux-policy-3.11.1-21.fc18.noarch
Any avc messages? ausearch -m avc -ts recent after the failure.
Here are the ausearch output for failed attempts as [1] a user assigned guest_u and [2] another user with default unconfined_u: ---- time->Wed Sep 19 20:57:09 2012 type=SYSCALL msg=audit(1348106229.432:287): arch=40000003 syscall=11 success=no exit=-13 a0=b7884188 a1=bfb0abd4 a2=b7890758 a3=0 items=0 ppid=988 pid=989 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts1 ses=14 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1348106229.432:287): avc: denied { transition } for pid=989 comm="sshd" path="/bin/bash" dev="sda3" ino=1046547 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=guest_u:guest_r:guest_t:s0 tclass=process ---- time->Wed Sep 19 21:05:39 2012 type=SYSCALL msg=audit(1348106739.576:347): arch=40000003 syscall=11 success=no exit=-13 a0=b81500c0 a1=bffe1c64 a2=b815ecc8 a3=0 items=0 ppid=1078 pid=1079 auid=1002 uid=1002 gid=1003 euid=1002 suid=1002 fsuid=1002 egid=1003 sgid=1003 fsgid=1003 tty=pts1 ses=16 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1348106739.576:347): avc: denied { transition } for pid=1079 comm="sshd" path="/bin/bash" dev="sda3" ino=1046547 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
Something is wrong. chroot_user_t should not be in the game.
openssh-6.1p1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I accidentaly didn't remove the sftp-chroot patch from the spec file so the chroot_user_t is still there. Sorry.
Will the openssh package be updated to a version without the sftp-chroot patch prior to the final release of FC18?
I've hit another issue with the whole concept. The F18 SELinux policy disallows setuid() call to confined users. A sshd process needs to do 3 steps: change its SELinux context, chroot() itself to a new directory, and change uid. SELinux context has to be changed before chroot() since we can't assume that there's the SELinux infrastructure in the chrooted dir. chroot() has to be called by uid 0 so setuid() must be called after chroot(). But since process is already running with the user's context, it's denied by the policy. Dan, would be possible to re-allow confined users to call setuid() as it is in Fedora 17?
I've prepared a test build with dropped the sftp-chroot patch. You can find it here [1]. There's completely dropped usage of sftp_t and chroot_user_t, and system configured SELinux users are used instead. It's strongly recommended to use guest_u for chrooted users. Also it might be a good idea to add a new SELinux user just for sftp sessions. It needs the change in the selinux-policy. Confined users needs to be allowed to call setuid() as described in comment 25. Before I push it to F18 update, I'd like to know if it's possible to do this change in selinux-policy. In the mean time, you need to create and load your custom SELinux module: # cat user-setuid.te module user-setuid 1.0; require { attribute userdomain; class capability setuid; } #============= staff_t ============== allow userdomain self:capability setuid; [1] http://plautrba.fedorapeople.org/openssh/830237/
openssh-6.1p1-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/openssh-6.1p1-2.fc18
Package openssh-6.1p1-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17159/openssh-6.1p1-2.fc18 then log in and leave karma (feedback).