On Tue, Mar 4, 2014 at 8:44 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/03/2014 08:37 PM, Andy Ruch wrote: >> 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. >> > The way sshd works is to setup a process running as the user without doing a > fork/exec. This is why we did a setcurrent in sshd. The problem we were > trying to solve, is if you have a user type that you do not want to prevent > running as a service, like guest_t, you can get around it by using sshd tunnels. > > By setting this process to guest_t rather then sshd_t, the policy works as you > would expect. Also since this process is running as the User UID it might be > able to be influenced by other processes with the same UID. Running as sshd_t > could be a risk. > > The problem with setcurrent is that it is not as clean as a setexeccon. It is > always better to do a fork/exec from an SELinux point of view. But if the app > does not implement this, we think setcurrent is a decent fall back. > If you are concerned with giving setcurrent to sshd_t IIRC you can add 'UsePrivilegeSeparation=no' to the sshd_config file and it won't try to bracket down it's privileges after authentication. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlMV2NEACgkQrlYvE4MpobOO2QCcDUTn3SaW4/jCH8/JGO7EHFdS > T2wAoOrgSD+YJmpat76aUkrmpg3iq7Ba > =obee > -----END PGP SIGNATURE----- > _______________________________________________ > 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. _______________________________________________ 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.
