Bug 524583 - setroubleshoot: SELinux is preventing the /usr/bin/kdm from using potentially mislabeled files (/home/mef/.Xauthority-c).
Summary: setroubleshoot: SELinux is preventing the /usr/bin/kdm from using potent...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:1840583d795...
: 566582 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-21 10:34 UTC by Mary Ellen Foster
Modified: 2010-02-23 20:26 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-09-21 15:15:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mary Ellen Foster 2009-09-21 10:34:10 UTC
The following was filed automatically by setroubleshoot:

Summary:

SELinux is preventing the /usr/bin/kdm from using potentially mislabeled files
(/home/mef/.Xauthority-c).

Detailed Description:

SELinux has denied kdm access to potentially mislabeled file(s)
(/home/mef/.Xauthority-c). This means that SELinux will not allow kdm to use
these files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is that
the files end up with the wrong file context which confined applications are not
allowed to access.

Allowing Access:

If you want kdm to access this files, you need to relabel them using restorecon
-v '/home/mef/.Xauthority-c'. You might want to relabel the entire directory
using restorecon -R -v '/home/mef'.

Additional Information:

Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:xauth_home_t:s0
Target Objects                /home/mef/.Xauthority-c [ file ]
Source                        kdm
Source Path                   /usr/bin/kdm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           kdm-4.3.1-3.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.31-3.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     (removed)
Platform                      Linux (removed) 2.6.31-2.fc12.i686 #1 SMP Thu Sep
                              10 00:41:03 EDT 2009 i686 i686
Alert Count                   6
First Seen                    Tue 15 Sep 2009 02:35:21 PM BST
Last Seen                     Mon 21 Sep 2009 10:57:48 AM BST
Local ID                      33c5b4da-0121-49c8-9888-11c87ac4dbcc
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1253527068.628:27): avc:  denied  { unlink } for  pid=1457 comm="kdm" name=".Xauthority-c" dev=sda5 ino=66 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:xauth_home_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1253527068.628:27): arch=40000003 syscall=10 success=no exit=-13 a0=bfaa12bb a1=0 a2=112bb8 a3=1 items=0 ppid=1417 pid=1457 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)


audit2allow suggests:

#============= xdm_t ==============
allow xdm_t xauth_home_t:file unlink;

Comment 1 Daniel Walsh 2009-09-21 13:29:52 UTC
SELinux does not handle have two files written in the same directory at the same time with different security labels.  I the case of kdm it is trying to write .xsession-errors and .Xauthority*

.xsession-errors has to allow all processes in the user domain to write to it, since this is where they report their errors.

.Xauthority wants very few processes to write to it, and most need to read.

So I label them differently  xauth_home_t and xdm_home_t.  xdm was changed to write the Xauth file in /var/run/

 echo $XAUTHORITY 
/var/run/gdm/auth-for-dwalsh-m67cxI/database

I believe this solves other problems also, around kerberized NFS.

Can we` get kdm to do something similar?

Comment 2 Rex Dieter 2009-09-21 13:36:31 UTC
Maybe?    kdmrc contains the option:

# Where to store authorization files.
# Default is "/var/run/xauth"
#AuthDir=/tmp

it's putting something in /var/run/xauth on my box (though, oops, that's currently an unowned directory).

Fwiw, is this something new to F-12?  I don't see any selinux-related issues on my F-11 box.

Comment 3 Daniel Walsh 2009-09-21 13:45:46 UTC
I don't know. But maybe this is an upgrade issue, so the user needs to change his defaults?

Comment 4 Mary Ellen Foster 2009-09-21 14:15:35 UTC
This is not an upgrade install -- I installed the alpha freshly a few weeks ago and have been updating against Rawhide since. I have exactly the same content in my kdmrc as Rex mentions in Comment #2.

Comment 5 Rex Dieter 2009-09-21 14:25:55 UTC
Any preference for kdm using /var/run/xauth vs /var/run/kdm here?  

The latter would be easier for folks upgrading (no/less config change), if that makes any difference.

Comment 6 Rex Dieter 2009-09-21 14:29:22 UTC
There's also this option:
# Where to put the user's X-server authorization file if ~/.Xauthority
# cannot be created.
# Default is "/tmp"
#UserAuthDir=

So, Dan, this is the one you'd rather be in /var/run somewhere too?

Comment 7 Daniel Walsh 2009-09-21 14:33:24 UTC
I would rather /var/run/kdm, since I think we already have the correct label
there.

Comment 8 Rex Dieter 2009-09-21 15:15:34 UTC
okie dokie, fixed in kde-settings-kdm-4.3-9

%changelog
* Mon Sep 21 2009 Rex Dieter <rdieter> - 4.3-9
- kdmrc: ForceUserAuthDir=true (#524583)

* Mon Sep 21 2009 Rex Dieter <rdieter> - 4.3-8
- kdmrc: use /var/run/kdm for pid/xauth (#524583)

Comment 9 Rex Dieter 2009-10-08 14:07:57 UTC
*** Bug 527843 has been marked as a duplicate of this bug. ***

Comment 10 Rex Dieter 2010-02-23 20:26:22 UTC
*** Bug 566582 has been marked as a duplicate of this bug. ***


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