Bug 487554 - With selinux on restarted processes may change their context
With selinux on restarted processes may change their context
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 517000
  Show dependency treegraph
 
Reported: 2009-02-26 12:36 EST by Michal Jaegermann
Modified: 2009-08-19 11:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-19 11:31:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2009-02-26 12:36:36 EST
Description of problem:

On a system with a remote access sometimes one needs to restart processes from cron (for whatever reasons).  If that process happens to be sshd then one (may?) end up with the following (a fragment of a 'pstree -Z' output):
....
 |-sshd(`system_u:system_r:system_crond_t:s0')
 |  `-sshd(`system_u:system_r:system_crond_t:s0')
 |     `-sshd(`system_u:system_r:system_crond_t:s0')
 |        `-bash(`system_u:system_r:system_crond_t:s0')
.....

If that happened then one is greeted with "Unable to get valid context for <whomever>" and with enforcing on one is practically banned from login.

The same "system_crond_t inheriting" may happen with other processes too but sshd appears to be here the most critical.

Version-Release number of selected component (if applicable):
selinux-policy-3.5.13-45

How reproducible:
repeatable although I am not absolutely sure what "right" conditions are

Additional info:
As long as Fedora 8 was in use I do not recall to ever seeing something like that but that changed after an upgrade to Fedora 10.
Comment 1 Daniel Walsh 2009-03-02 21:57:04 EST
How are you restarting the processes.

If you are using the init scripts it looks like it should work

service sshd restart

Looking at policy it says that
system_crond_t can exec initrc_exec_t and transition to initrc_t which then will start sshd_exec_t as sshd_t.
Comment 2 Michal Jaegermann 2009-03-03 00:34:49 EST
> How are you restarting the processes.

Exactly how you are suggesting. 'service sshd restart' although not directly
but from a script which is run by cron.

> .. it looks like it should work

I am afraid that it gives me trouble.  This is how the corresponding
fragment of 'pstree -Z' looks like right when things are "normal":
....
 |-sshd(`system_u:system_r:sshd_t:s0-s0:c0.c1023')
 |  `-sshd(`system_u:system_r:sshd_t:s0-s0:c0.c1023')
 |     `-sshd(`system_u:system_r:sshd_t:s0-s0:c0.c1023')
 |        `-bash(`unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023')

As mentioned before the system in question was running F8 without any incidents.  It got upgraded to F10 and it ended in a state like in the report already a few times.  There are no on it any "selinux hacks" and custom policies; only what a sequence of updates put there.

If I am running 'service sshd restart' from a command line then there is no trouble but that is likely not a big surprise.
Comment 3 Daniel Walsh 2009-03-03 15:00:57 EST
Miroslav change the line that currently says

init_spec_domtrans_script(system_crond_t)

to

init_domtrans_script(system_crond_t)

Which should fix this bug.

Michael if you want you can create a te file 

# cat > mycron.te << _EOF
policy_module(mycron,1.0)

require {
	type system_crond_t;
}

#============= unconfined_t ==============
init_domtrans_script(system_crond_t)

__eof

# make -f /usr/share/selinux/devel/Makefile 
# semodule -i mycron.pp

Which should fix your problem until you get the update.
Comment 4 Michal Jaegermann 2009-03-03 19:45:58 EST
> ... if you want you can create a te file 
Thanks!  I will see how it goes.
Comment 5 Miroslav Grepl 2009-03-06 08:14:39 EST
Fixed in selinux-policy-3.5.13-48.fc10
Comment 6 Michal Jaegermann 2009-08-18 10:41:29 EDT
I did not see the issue after updates mentioned in comment #5.  Does this show up elsewhere?
Comment 7 Miroslav Grepl 2009-08-19 11:31:30 EDT
Closing all bugs that have been in modified for over a month.  Please reopen if
the bug is not actually fixed.

Note You need to log in before you can comment on or make changes to this bug.