Bug 120108

Summary: su'ing to root causes pam_xauth error
Product: [Fedora] Fedora Reporter: Albert Strasheim <13640887>
Component: policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: gbpeck, pgraner, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-06-14 21:16:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
policy-su.patch none

Description Albert Strasheim 2004-04-06 00:53:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
Su'ing to the root user from a normal user in an X terminal causes the
following action to be denied by SELinux:

Apr  6 02:54:38 asok kernel: audit(1081212878.255:0): avc:  denied  {
write } for  pid=3231 exe=/bin/su name=root dev=hda5 ino=1310721
scontext=user_u:user_r:user_su_t
tcontext=root:object_r:staff_home_dir_t tclass=dir

This causes the following pam_xauth error:

Apr  6 02:54:38 asok su[3231]: pam_xauth: error creating temporary
file `/root/.xauthrBhOGC': Permission denied

Version-Release number of selected component (if applicable):
policy-1.9.2-9 pam-0.77-38

How reproducible:
Always

Steps to Reproduce:
1. su to root from normal user in X term
2. look in /var/log/messages
    

Actual Results:  pam_xauth error

Expected Results:  pam_xauth should be able to create temporary xauth file

Additional info:

Comment 1 Daniel Walsh 2004-04-06 02:01:43 UTC
Fixed in rawhide.

policy-1.9.2-12

Comment 2 Gary Peck 2004-04-29 19:54:56 UTC
I don't have permission to reopen this bug, but I'm still seeing this
problem with policy-1.11.2-18. The avc message, however, is now a
little bit different:

audit(1083040037.542:0): avc:  denied  { add_name } for  pid=2297
exe=/bin/su name=.xauthyWmC0t scontext=user_u:user_r:user_su_t
tcontext=root:object_r:staff_home_dir_t tclass=dir

I still get the same pam_xauth error as above.

Comment 3 Tim Waugh 2004-05-10 10:31:34 UTC
I still see audit messages from 'su' user_r -> sysadm_r as well.  I
don't see add_name, but instead: search in user_home_t (~/.xauth).

This comment in domains/user.te indicates that the xauthority stuff
isn't meant to work in SELinux:

# When an ordinary user domain runs su, su may try to
# update the /root/.Xauthority file, and the user shell may
# try to update the shell history. This isnt allowed, but
# we dont need to audit it.

Here is the audit message I see:

audit(1084183402.517:0): avc:  denied  { search } for  pid=29842
exe=/bin/su name=.xauth dev=hda6 ino=261622
scontext=user_u:user_r:user_su_t
tcontext=system_u:object_r:user_home_t tclass=dir

and here is the change to avoid auditing it:

--- ./domains/user.te.su        2004-05-10 11:04:13.213489808 +0100
+++ ./domains/user.te   2004-05-10 11:05:26.664323584 +0100
@@ -18,7 +18,7 @@
 # update the /root/.Xauthority file, and the user shell may
 # try to update the shell history. This isnt allowed, but
 # we dont need to audit it.
-dontaudit $1_su_t sysadm_home_dir_t:dir  search;
+dontaudit $1_su_t { sysadm_home_dir_t $1_home_t }:dir  search;
 dontaudit $1_su_t sysadm_home_t:dir  { read getattr search write
add_name remove_name };
 dontaudit $1_su_t sysadm_home_t:file { read getattr create write link
unlink }; ') dnl ifdef su.te


Comment 4 Daniel Walsh 2004-05-11 15:03:13 UTC
Added 

dontaudit $1_su_t { sysadm_home_dir_t staff_home_t }:dir  search;

to policy-1.11.3-5


Comment 5 Tim Waugh 2004-05-12 15:11:05 UTC
It needs to be

dontaudit $1_su_t { sysadm_home_dir_t $1_home_t }:dir search;

I'm still getting:

audit(1084373394.830:0): avc:  denied  { search } for  pid=29955
exe=/bin/su name=.xauth dev=hda6 ino=261622
scontext=user_u:user_r:user_su_t
tcontext=system_u:object_r:user_home_t tclass=dir

Comment 6 Tim Waugh 2004-05-12 15:15:58 UTC
Created attachment 100185 [details]
policy-su.patch

Patch relative to 1.11.3-5.

Comment 7 Gary Peck 2004-05-19 02:37:06 UTC
With policy-1.11.3-5, audit2allow says I still need:

allow user_su_t staff_home_dir_t:dir { add_name remove_name };
allow user_su_t staff_home_dir_t:file { create setattr };

Comment 8 Daniel Walsh 2004-06-02 18:37:25 UTC
Try out selinux-policy-strict-1.13.2-7

Comment 9 Gary Peck 2004-06-03 05:14:14 UTC
I needed to use my rawhide computer for actual work :) and had to
switch to selinux-policy-targeted in the meantime. I won't have time
to test this for the foreseeable future.