|Main Archive Page > Month Archives > gentoo-hardened archives|
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
> 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.
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.