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.
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.
> 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.
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.
> ... if you want you can create a te file Thanks! I will see how it goes.
Fixed in selinux-policy-3.5.13-48.fc10
I did not see the issue after updates mentioned in comment #5. Does this show up elsewhere?
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.