Description of problem: Something's wrong with selinux, the 'service' command, sudo, sshd, pam, or some combination of them. If I type: $ sudo service sshd restart Then sshd fails all incoming connections with: Unable to get valid context for <username> If, on the other hand, I start ssh from a genuine root shell with: # service sshd restart it works fine. If I modify /etc/pam.d/sshd to add "verbose debug" to pam_selinux, then the bad state logs this: sshd[24846]: pam_selinux(sshd:session): Security context unconfined_u:system_r:policykit_grant_t:s0-s0:c0.c1023 is not allowed for unconfined_u:system_r:policykit_grant_t:s0-s0:c0.c1023 sshd[24846]: pam_selinux(sshd:session): Unable to get valid context for luto sshd[24846]: pam_unix(sshd:session): session opened for user luto by (uid=0) sshd[24846]: error: PAM: pam_open_session(): Authentication failure sshd[24846]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument and the good state logs this: sshd[3904]: pam_selinux(sshd:session): Open Session sshd[3904]: pam_selinux(sshd:session): Username= luto SELinux User = unconfined_u Level= s0-s0:c0.c1023 sshd[3904]: pam_selinux(sshd:session): Selected Security Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 The only thing suspicious that I can find is that /proc/`pidof sshd`/attr/current says ...:unconfined_execmem_t:... in the bad case but ...:sshd_t:... in the good case. I don't see anything strange about sudo or sshd's environments. I tried looking at the code that seems to look up user contexts, but that code is too incomprehensible and too poorly documented (or I just can't find the docs) for me to make any headway. Version-Release number of selected component (if applicable): This bug exists on F13 and F14, fully updated (and less-than-fully updated, although I never noticed it before October 2010). How reproducible: 100%, on both machines that I've (accidentally) tried it on. Steps to Reproduce: 1. Log in as someone other than root. 2. Run 'sudo service sshd restart' 3. Try to ssh in. Bug filed against selinux-policy-targeted because initscripts and sshd both seem less likely to find the right people.
[repost, because my comment got eaten, I think] I can trigger the bug from an otherwise-good root shell with: # runcon -t unconfined_execmem_t service sshd restart and I can prevent the bug from gnome-terminal with: $ sudo runcon -t unconfined_t service sshd restart So there's something wrong with the policy for unconfined_execmem_t and/or libselinux's lookup of user contexts. (I have basically no clue how that stuff is supposed to work and I've never found any reasonable documentation for it.)
What is the /usr/bin/sudo labeled? ls -lZ /usr/bin/sudo ---s--x--x. root root system_u:object_r:sudo_exec_t:s0 /usr/bin/sudo
On the affected F13 machine: $ ls -Z /usr/bin/sudo ---s--x--x. root root system_u:object_r:sudo_exec_t:s0 /usr/bin/sudo On the F14 machine: $ ls -Z /usr/bin/sudo ---s--x--x. root root system_u:object_r:sudo_exec_t:s0 /usr/bin/sudo I tried touch /.autorelabel; reboot on the F13 machine and the bug didn't go away.
What does ps -eZ | grep sshd look like when the connections fail? runcon -t unconfined_execmem_t service sshd restart Would leave sshd running as unconfined_execmem_t which would cause this problem, since there is no transition from unconfined_execmem_t to sshd_t
$ ps -eZ |grep sshd unconfined_u:system_r:unconfined_execmem_t:s0-s0:c0.c1023 21074 ? 00:00:00 sshd So should the service script be fixed? Or the policy? Out of curiosity, where on earth does policykit_grant_t come from?
I've the same problem with the same symptoms, except that I use su rather than sudo.
You guys are saying that if you execute sudo service sshd restart Or su -c service sshd restart The process ends up running as unconfined_execmem_t?
Yes. $ sudo service sshd restart Stopping sshd: [FAILED] Starting sshd: [ OK ] $ ps -eZ |grep sshd unconfined_u:system_r:unconfined_execmem_t:s0-s0:c0.c1023 2806 ? 00:00:00 sshd $ getsebool allow_execmem allow_execmem --> on
Exactly: [hedayat@localhost ~]% ps -eZ |grep sshd [hedayat@localhost ~]% su -c "service sshd start" Password: Starting sshd: [ OK ] [hedayat@localhost ~]% ps -eZ |grep sshd unconfined_u:system_r:unconfined_execmem_t:s0-s0:c0.c1023 16023 ? 00:00:00 sshd [hedayat@localhost ~]%
ls -lZ /sbin/service /etc/init.d/sshd /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_initrc_exec_t:s0 /etc/init.d/sshd -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/service -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd
I'm not sure if that's a question, but I get the same thing: $ ls -lZ /sbin/service /etc/init.d/sshd /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_initrc_exec_t:s0 /etc/init.d/sshd -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/service -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd However, this might be relevant: $ id -Z unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023
Yes, matches exactly with my system. I've had this problem with fresh installation of F13 and F14.
Yes that is the problem. The question is why are you logging in as unconfined_execmem_t rather then unconfined_t. Are you running a special shell? Hedayat, what does id -Z show for you?
I'm just using bash. The only strange thing I can think of that I did is to persistently set allow_execmem on.
[hedayat@localhost Applications/CollanosWorkplace]% id -Z unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 (I'm using zsh)
And both of you logged in via gdm? If you ssh localhost on the box and login, does the id -Z show unconfined_t?
Yes, I logged in via GDM If I set the enforcing mode to permissive I get: [hedayat@localhost ~]% ssh localhost hedayat@localhost's password: Unable to get valid context for hedayat Last login: Sat Dec 11 05:00:49 2010 from localhost.localdomain [hedayat@localhost ~]% id -Z unconfined_u:system_r:unconfined_execmem_t:s0-s0:c0.c1023 [hedayat@localhost ~]%
I get unconfined_execmem_t from gdb and unconfined_t from sshd.
What is output by find / -context "*execmem_exec_t*" 2> /dev/null Hedayat you need to get sshd running with the right context.
Aha! Sorry :P : [hedayat@localhost ~]% ssh localhost hedayat@localhost's password: Last login: Mon Dec 13 19:59:17 2010 from localhost.localdomain [hedayat@localhost ~]% id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [hedayat@localhost ~]% find / -context "*execmem_exec_t*" 2> /dev/null /usr/bin/valgrind /usr/bin/dosbox /usr/bin/compiz /usr/bin/plasma-desktop [hedayat@localhost ~]%
Well, yeah, it's compiz! If I disable Desktop Effects and start a new terminal, it'll have the desired context and then everything is fine. :)
What happens if you execute chcon -t bin_t /usr/bin/compiz And turn the desktop effects back on?
Well, apparently nothing (works normally). I got no SELinux error messages. And nothing special in log files. :P
Hedayat, so if you now disable the desktop effects and execute # restorecon -v /usr/bin/compiz and turn the desktop effects back on , you see the problem again? Dan, afaik compiz sometimes needs execmem. It depends on graphics drivers.
Yes, I do. The gnome-terminal inherits context from compiz and so the other childs...
I think we shold change compiz back to bin_t and force anyone who needs execmem to turn on allow_execmem. To prevent this problem.
Ok, will change back to bin_t.
Fixed in selinux-policy-3.9.7-17.fc14
selinux-policy-3.9.7-18.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-18.fc14
selinux-policy-3.9.7-18.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-18.fc14
selinux-policy-3.9.7-18.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.