Bug 661146

Summary:	sudo service sshd restart causes "Unable to get valid context for ..."
Product:	[Fedora] Fedora	Reporter:	Andy Lutomirski <luto>
Component:	selinux-policy-targeted	Assignee:	Miroslav Grepl <mgrepl>
Status:	CLOSED ERRATA	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	low
Version:	14	CC:	dwalsh, hedayatv
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	selinux-policy-3.9.7-18.fc14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-12-21 23:59:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Lutomirski 2010-12-07 21:56:44 UTC

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.

Comment 1 Andy Lutomirski 2010-12-08 18:03:42 UTC

[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.)

Comment 2 Daniel Walsh 2010-12-08 20:43:56 UTC

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

Comment 3 Andy Lutomirski 2010-12-08 20:49:49 UTC

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.

Comment 4 Daniel Walsh 2010-12-10 21:45:03 UTC

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

Comment 5 Andy Lutomirski 2010-12-10 22:00:56 UTC

$ 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?

Comment 6 Hedayat Vatankhah 2010-12-11 01:33:22 UTC

I've the same problem with the same symptoms, except that I use su rather than sudo.

Comment 7 Daniel Walsh 2010-12-13 14:46:12 UTC

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?

Comment 8 Andy Lutomirski 2010-12-13 14:57:09 UTC

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

Comment 9 Hedayat Vatankhah 2010-12-13 14:58:40 UTC

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 ~]%

Comment 10 Daniel Walsh 2010-12-13 15:13:30 UTC

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

Comment 11 Andy Lutomirski 2010-12-13 15:32:58 UTC

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

Comment 12 Hedayat Vatankhah 2010-12-13 15:36:26 UTC

Yes, matches exactly with my system. I've had this problem with fresh installation of F13 and F14.

Comment 13 Daniel Walsh 2010-12-13 15:46:23 UTC

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?

Comment 14 Andy Lutomirski 2010-12-13 15:54:17 UTC

I'm just using bash.  The only strange thing I can think of that I did is to persistently set allow_execmem on.

Comment 15 Hedayat Vatankhah 2010-12-13 16:05:24 UTC

[hedayat@localhost Applications/CollanosWorkplace]% id -Z
unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023

(I'm using zsh)

Comment 16 Daniel Walsh 2010-12-13 16:13:09 UTC

And both of you logged in via gdm?

If you ssh localhost on the box and login, does the id -Z show unconfined_t?

Comment 17 Hedayat Vatankhah 2010-12-13 16:31:22 UTC

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 ~]%

Comment 18 Andy Lutomirski 2010-12-13 16:53:26 UTC

I get unconfined_execmem_t from gdb and unconfined_t from sshd.

Comment 19 Daniel Walsh 2010-12-13 17:20:47 UTC

What is output by  

find / -context "*execmem_exec_t*" 2> /dev/null

Hedayat you need to get sshd running with the right context.

Comment 20 Hedayat Vatankhah 2010-12-13 19:44:20 UTC

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 ~]%

Comment 21 Hedayat Vatankhah 2010-12-13 19:48:16 UTC

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. :)

Comment 22 Daniel Walsh 2010-12-13 20:57:32 UTC

What happens if you execute 

chcon -t bin_t /usr/bin/compiz 

And turn the desktop effects back on?

Comment 23 Hedayat Vatankhah 2010-12-13 21:07:20 UTC

Well, apparently nothing (works normally). I got no SELinux error messages. And nothing special in log files. :P

Comment 24 Miroslav Grepl 2010-12-14 09:52:20 UTC

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.

Comment 25 Hedayat Vatankhah 2010-12-14 10:33:19 UTC

Yes, I do. The gnome-terminal inherits context from compiz and so the other childs...

Comment 26 Daniel Walsh 2010-12-14 13:59:58 UTC

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.

Comment 27 Miroslav Grepl 2010-12-14 14:11:44 UTC

Ok, will change back to bin_t.

Comment 28 Miroslav Grepl 2010-12-15 14:11:51 UTC

Fixed in selinux-policy-3.9.7-17.fc14

Comment 29 Fedora Update System 2010-12-16 15:54:38 UTC

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

Comment 30 Fedora Update System 2010-12-17 08:36:48 UTC

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

Comment 31 Fedora Update System 2010-12-21 23:58:41 UTC

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.