Help with su (RESOLVED)
 

On 11/25/2011 08:32 PM, Stan Sander wrote:
> One of the more important things that is currently broken on my system
> when I switch on enforcing mode for SELinux is the su command. Mostly
> likely I've overlooked something so am asking here first before filing a
> bug on it.

After doing some more searching, reading, and educating of myself I have
been able to achieve the behavior I was wanting from the su command,
namely change my regular Linux uid to 0 and be able to launch graphical
programs if necessary when logged in to a desktop session. What I
discovered leaves my SELinux user id set to the user I originally logged
in as, which from a security and accountability standpoint is not a bad
thing, but the role and type are updated so all the transitions needed
for the policy to function as intended can occur. However, my Linux uid
is 0 so things that need that work. Probably a simple concept for all
you seasoned SELinux folk, but wanted to document it here for the
benefit of others who may find this in the archives.

My answer -- removing the calls to pam_selinux.so from the su file in
pam.d and also removing the calls to pam_xauth.so from the su and
newrole files. These (xauth) generated avc denials when they couldn't
access root's home area at /root due to (I think) ubac constraints.
The last step a very simple script I called sesu

#!/bin/bash
echo -n "X server: "
xhost local:localhost
echo -n "Enter root "
su -c "echo -n "Enter current user " && newrole -r sysadm_r"

If your PAM config doesn't allow the current user to su, then they get
permission denied.
If SELinux doesn't allow the current user to transition to a sysadm_r
then you get a root shell, but with limited capability.


--
Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
PR - Cindy and Jenny - Sammamish, WA NWR
http://www.cci.org

Help with su (RESOLVED)
 

On Sat, Nov 26, 2011 at 10:00:01PM -0700, Stan Sander wrote:
> After doing some more searching, reading, and educating of myself I have
> been able to achieve the behavior I was wanting from the su command,
> namely change my regular Linux uid to 0 and be able to launch graphical
> programs if necessary when logged in to a desktop session. What I
> discovered leaves my SELinux user id set to the user I originally logged
> in as, which from a security and accountability standpoint is not a bad
> thing, but the role and type are updated so all the transitions needed
> for the policy to function as intended can occur. However, my Linux uid
> is 0 so things that need that work. Probably a simple concept for all
> you seasoned SELinux folk, but wanted to document it here for the
> benefit of others who may find this in the archives.
>
> My answer -- removing the calls to pam_selinux.so from the su file in
> pam.d and also removing the calls to pam_xauth.so from the su and
> newrole files. These (xauth) generated avc denials when they couldn't
> access root's home area at /root due to (I think) ubac constraints.
> The last step a very simple script I called sesu
>
> #!/bin/bash
> echo -n "X server: "
> xhost local:localhost
> echo -n "Enter root "
> su -c "echo -n "Enter current user " && newrole -r sysadm_r"
>
> If your PAM config doesn't allow the current user to su, then they get
> permission denied.
> If SELinux doesn't allow the current user to transition to a sysadm_r
> then you get a root shell, but with limited capability.

Hi Stan,

This isn't really the way it is meant to resolve. From your denials, I
gather that you were still running in staff_r role. You need to transition
to sysadm_r role first and then try to perform your administrative tasks.

Wkr,
Sven Vermeulen

Help with su (RESOLVED)
 

On 11/27/2011 10:38 AM, Sven Vermeulen wrote:
>
> Hi Stan,
>
> This isn't really the way it is meant to resolve. From your denials, I
> gather that you were still running in staff_r role. You need to transition
> to sysadm_r role first and then try to perform your administrative tasks.
>
> Wkr,
> Sven Vermeulen
Sven,

Thanks for the tip. I was running in staff_r when I got the denials. I
thought I read somewhere that staff was allowed to su, so never thought
the difference of when I entered the newrole to be that significant.
Anyway, I'll call newrole first but it still appears as though I need to
keep the calls to pam_selinux out of the su file as it fails when they
are in. Also pam_xauth doesn't appear as though it's able to play with
selinux, at least not inside the su file.

--
Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
PR - Cindy and Jenny - Sammamish, WA NWR
http://www.cci.org

Help with su (RESOLVED)
 

On Sun, Nov 27, 2011 at 12:48:14PM -0700, Stan Sander wrote:
> Thanks for the tip. I was running in staff_r when I got the denials. I
> thought I read somewhere that staff was allowed to su, so never thought
> the difference of when I entered the newrole to be that significant.
> Anyway, I'll call newrole first but it still appears as though I need to
> keep the calls to pam_selinux out of the su file as it fails when they
> are in. Also pam_xauth doesn't appear as though it's able to play with
> selinux, at least not inside the su file.

Heh, my bad. There is no need to put pam_selinux for su in the first place.
At least, I don't have it on my systems. The only place where pam_selinux is
called is in the system-login definition for PAM (which is sourced by login,
slim and sshd PAM definitions).

Meh.

Sven Vermeulen