Hello, I'm implementing a custom SELinux policy based on the reference policy for a secure RHEL 6.5 system. Currently, my policy does not allow 'setcurrent' for sshd_t and I'm seeing the appropriate AVCs associated to this. However, even with these AVCs, everything appears to work. I still end up with a bash process running as staff_t. The only difference I see using 'ps -efZ' is the context of parent process of the bash shell: PERMISSIVE: system_u:system_r:sshd_t:s0-s0:c0.c1023 root 29470 1520 ... sshd: myuser [priv] myuser_u:staff_r:staff_t:s0-s0:c0.c1023 myuser 29475 29470 ... sshd: myuser@pts/0 myuser_u:staff_r:staff_t:s0-s0:c0.c1023 myuser 29476 29475 ... -bash ENFORCING (context on 2nd line different): system_u:system_r:sshd_t:s0-s0:c0.c1023 root 29505 1520 ... sshd: myuser [priv] system_u:system_r:sshd_t:s0-s0:c0.c1023 myuser 29510 29505 ... sshd: myuser@pts/0 myuser_u:staff_r:staff_t:s0-s0:c0.c1023 myuser 29511 29510 ... -bash Does this second process labeled as "sshd_t" provide any usability or security issues? Digging into the policy code more, I see comments in domain.te along the lines of "setcurrent breaks process tranquility" and "don't use it if you don't understand it". Could someone provide some more details regarding when to use 'setcurrent' for a secure system? Also, I understand that the RHEL Targeted policy has a completely different use case than my custom policy. However, why is it allowed in the Targeted policy if the sshd appears to work without it? Thanks, Andy Ruch _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
