Bug 120108 - su'ing to root causes pam_xauth error
su'ing to root causes pam_xauth error
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2004-04-05 20:53 EDT by Albert Strasheim
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-14 17:16:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
policy-su.patch (794 bytes, patch)
2004-05-12 11:15 EDT, Tim Waugh
no flags Details | Diff

  None (edit)
Description Albert Strasheim 2004-04-05 20:53:31 EDT
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
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:

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-05 22:01:43 EDT
Fixed in rawhide.

Comment 2 Gary Peck 2004-04-29 15:54:56 EDT
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 06:31:34 EDT
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
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 11:03:13 EDT

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 11:11:05 EDT
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
tcontext=system_u:object_r:user_home_t tclass=dir
Comment 6 Tim Waugh 2004-05-12 11:15:58 EDT
Created attachment 100185 [details]

Patch relative to 1.11.3-5.
Comment 7 Gary Peck 2004-05-18 22:37:06 EDT
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 14:37:25 EDT
Try out selinux-policy-strict-1.13.2-7
Comment 9 Gary Peck 2004-06-03 01:14:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.