Bug 922958 - SELinux is preventing /usr/sbin/lightdm from 'create' accesses on the file .dmrc.T5D7TW.
Summary: SELinux is preventing /usr/sbin/lightdm from 'create' accesses on the file .d...
Keywords:
Status: CLOSED DUPLICATE of bug 963238
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:972cd815be4eb2c5436eef3b201...
: 924003 951316 951966 955851 (view as bug list)
Depends On:
Blocks: F19Beta-accepted, F19BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-03-18 21:12 UTC by Dan Mashal
Modified: 2013-05-15 20:29 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-15 20:29:02 UTC
Type: ---


Attachments (Terms of Use)
Output of AVC Message - 2013-05-15 (2.31 KB, text/plain)
2013-05-15 19:12 UTC, Robert Lightfoot
no flags Details

Description Dan Mashal 2013-03-18 21:12:05 UTC
Description of problem:
SELinux is preventing /usr/sbin/lightdm from 'create' accesses on the file .dmrc.T5D7TW.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that lightdm should be allowed create access on the .dmrc.T5D7TW file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep lightdm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:user_home_t:s0
Target Objects                .dmrc.T5D7TW [ file ]
Source                        lightdm
Source Path                   /usr/sbin/lightdm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           lightdm-1.5.1-1.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-20.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.9.0-0.rc3.git0.3.fc20.x86_64 #1
                              SMP Mon Mar 18 00:44:23 UTC 2013 x86_64 x86_64
Alert Count                   2
First Seen                    2013-03-18 13:44:22 PDT
Last Seen                     2013-03-18 14:09:05 PDT
Local ID                      c41f2ddb-fa16-470e-80cb-2c248406d1b9

Raw Audit Messages
type=AVC msg=audit(1363640945.989:316): avc:  denied  { create } for  pid=411 comm="lightdm" name=".dmrc.T5D7TW" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file


type=SYSCALL msg=audit(1363640945.989:316): arch=x86_64 syscall=open success=no exit=EACCES a0=14c6490 a1=c2 a2=1b6 a3=0 items=0 ppid=1 pid=411 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 ses=4294967295 tty=(none) comm=lightdm exe=/usr/sbin/lightdm subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)

Hash: lightdm,xdm_t,user_home_t,file,create

audit2allow

#============= xdm_t ==============
allow xdm_t user_home_t:file create;

audit2allow -R
require {
	type xdm_t;
}

#============= xdm_t ==============
userdom_manage_user_home_content_files(xdm_t)


Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc3.git0.3.fc20.x86_64
type:           libreport

Comment 1 Miroslav Grepl 2013-03-19 12:03:46 UTC
Ok, I am able to reproduce it

type=AVC msg=audit(1363551167.500:327): avc:  denied  { create } for  pid=737 comm="lightdm" name=".dmrc.QLEXTW" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1363551167.500:327): avc:  denied  { write } for  pid=737 comm="lightdm" path="/home/mgrepl/.dmrc.QLEXTW" dev="dm-8" ino=666940 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1363551167.500:327): arch=c000003e syscall=2 success=yes exit=12 a0=215cb70 a1=c2 a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 ses=4294967295 tty=(none) comm="lightdm" exe="/usr/sbin/lightdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1363551167.514:328): avc:  denied  { rename } for  pid=737 comm="lightdm" name=".dmrc.QLEXTW" dev="dm-8" ino=666940 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file

Comment 2 Miroslav Grepl 2013-03-19 12:09:38 UTC
Does .dmrc.QLEXTW need to be random?

Comment 3 Dan Mashal 2013-03-19 19:45:26 UTC
Yes, it appears to be random.

Comment 4 Rex Dieter 2013-03-19 20:14:57 UTC
We can make it not be random, if that helps.

Comment 5 Daniel Walsh 2013-03-19 23:38:18 UTC
Or could it be placed in a subdir or ~/.cache?  Say 
~/.cache/lightdm/dmrc

Or just 

~/.cache/dmrc

Comment 6 Rex Dieter 2013-03-20 14:58:01 UTC
Sure, we can adjust things to use something under ~/.cache as a temp filename instead (before it gets renamed back to ~/.dmrc )

Comment 7 Daniel Walsh 2013-03-20 15:17:46 UTC
Ok so the location in ~/.dmrc is critical.

Comment 8 Rex Dieter 2013-03-20 15:21:12 UTC
Yes, it's a standard/convention for DM's to store previous session information there.

Comment 9 Daniel Walsh 2013-03-20 15:29:02 UTC
The basic problem is we can handle file creations with a fixed name.  But not with a mis name.  We can allow the X login programs to create any content in the ~/ directory as xdm_home_t, but this forces us to allow the creation of any file if it does not exist.  From a security point of view it would be nice to only allow the creation of 

/home/[^/]*/\.dmrc.*	--	unconfined_u:object_r:xdm_home_t:s0
/home/[^/]*/\.cache/gdm(/.*)?	unconfined_u:object_r:xdm_home_t:s0
/home/[^/]*/\.xsession-errors.*	--	unconfined_u:object_r:xdm_home_t:s0

Of ~/.dmrc and .xsession-errors.

We could also setup a special directory under ~/.cache that would allow us to get the labels right.

IE Allow lightdm to write to 

/home/.cache/lightdm/dmrc

Then we could get it right.  We could theoretically allow a rename to ~/.dmrc.

But is there really a reason for .dmrc versus /home/.cache/lighttm/dmrc?

Isn't lightdm the only login manager that is going to use this?

Comment 10 Rex Dieter 2013-03-20 15:34:22 UTC
All DM's I'm aware of support use of ~/.dmrc ,lightdm and kdm at least.  I wouldn't be surprised if gdm changed or deprecated it though.  (I'll go check...)

That said, I'm open to changing that to some other better known location if it makes selinux happier.

Comment 11 Rex Dieter 2013-03-20 15:54:59 UTC
Hrm, even though gdm source comments seem to reference dmrc in several places, it seems it is indeed no longer used, in favor of querying accountsservice.  See also:
http://lxnay.wordpress.com/2011/09/13/yet-another-gnomegdm-3-idiocy-dropping-dmrc-support/
(if you get look beyond the trollish rants)

even though it's still indeed documented @
https://help.gnome.org/admin/gdm/stable/configuration.html.en

Comment 12 Rex Dieter 2013-03-20 15:57:39 UTC
and for extra giggles, see also bug #617465

Comment 13 Miroslav Grepl 2013-03-21 08:37:11 UTC
*** Bug 924003 has been marked as a duplicate of this bug. ***

Comment 14 Satish Balay 2013-03-25 22:51:23 UTC
Description of problem:
This is a kvm VirtualMachine with rawhide installed [a few months ago] updated to latest rawhide a couple of days back.

The host is running F18 with 3.9.0-0.rc4.git0.2.fc20.x86_64

On bootup I do not see lightdm window manager. [just a blank screen]. There is a console message: [perhaps unrelated]?
 *ERROR* qxl too old, doesn't support client_monitors_config, use xf86-video-qxl in user mode

I can get lightdm to comeup after Alt-Ctrl-F2, Alt-Ctrl-F1

Once I login [to xfce] - I see this selinux message.

I tried deleting all selinux messages, run 'touch /.autorelabel', reboot - and login - and again see this message.

Hence reporting to bugzilla.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.2.fc20.x86_64
type:           libreport

Comment 15 Daniel Walsh 2013-03-26 19:59:05 UTC
Miroslav lets add a boolean to allow xdm_t to write xdm_home_t content in the users homedir.

Comment 16 Robert Lightfoot 2013-04-01 00:56:28 UTC
Description of problem:
F19-Alpha-TC3-i386
QA:Testcase Partitioning on Software Raid
XFCE Default Setup
SEAlert at first login.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.1.fc19.i686.PAE
type:           libreport

Comment 17 Rex Dieter 2013-04-01 01:22:26 UTC
reassigning to selinux-policy-targetted per comment #15

Comment 18 Robert Lightfoot 2013-04-01 15:13:13 UTC
Description of problem:
initial login startup f19-tc3-alpha-i386

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.1.fc19.i686.PAE
type:           libreport

Comment 20 Miroslav Grepl 2013-04-12 10:28:53 UTC
*** Bug 951316 has been marked as a duplicate of this bug. ***

Comment 23 Rex Dieter 2013-04-15 02:29:00 UTC
*** Bug 951966 has been marked as a duplicate of this bug. ***

Comment 24 Jan Sedlák 2013-04-19 09:37:42 UTC
Description of problem:
Booted XFCE live, Fedora 19 RC4.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
type:           libreport

Comment 25 Mukundan Ragavan 2013-04-22 03:51:53 UTC
Just a "me too" and adding myself to cc.

Comment 26 Miroslav Grepl 2013-04-24 13:06:23 UTC
*** Bug 955851 has been marked as a duplicate of this bug. ***

Comment 27 Robert Lightfoot 2013-04-24 16:46:37 UTC
Description of problem:
Initial startup xfce desktop install

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
type:           libreport

Comment 28 Miroslav Grepl 2013-04-26 08:32:13 UTC
I am working on a fix.

Comment 30 Sjoerd Mullender 2013-05-01 09:31:23 UTC
Description of problem:
Just booting and logging in.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Comment 31 Dan Mashal 2013-05-04 06:40:02 UTC
Please fix this ASAP. It is preventing the ability to shutdown via MATE.

Comment 32 klaus 2013-05-05 19:09:24 UTC
>>> Please fix this ASAP. It is preventing the ability to shutdown via MATE.
Literally true and annoying to have the same 'problem' turning up again and
again. I did download some updates and there was peace and improvement in the 'Schrödinger Cat' -alpha-system for some days, only to find that Selinux
came up with exactly the same safety warning again today, back to zero so to say.
This Fedora 19 seems to turn to more contradictions than bearable for the 'patient' user, hope the final stable version will render something to live with and worth being labelled with such a promising name. 

Thanks for your time and efforts anyway for sure, one could guesss its not exactly an easy thing to cope with.

Comment 33 klaus 2013-05-06 07:16:17 UTC
Description of problem:
Selinux guggests to do
# grep lightdm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
to have access for lightdm standardly OKed.
So I drop the two command lines to my MATE-terminals shell, which seems to
be accepted and going OK, but the next day the same
Selinux alarm comes up again, cause lightdm standing in front
of some file, trying to access it, just as if nothing has changed
or as if the grep - semodule command did effect nothing at all.
It is totally ok with me to grant lightdm access but how to switch
that alarm/warning off? 

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.i686.PAE
type:           libreport

Comment 34 Miroslav Grepl 2013-05-06 09:28:39 UTC
commit 755dfcf4a441d806c6fe57d5134950f847e90183
Author: Miroslav Grepl <mgrepl@redhat.com>
Date:   Mon May 6 11:27:35 2013 +0200

    Remove userdom_home_manager for xdm_t and move all rules to xserver.te directly
    Add new xdm_write_home boolean to allow xdm_t to create files in HOME dirs with xdm_home_t

Comment 35 Miroslav Grepl 2013-05-06 09:40:53 UTC
Just building a new policy for testing.

Comment 37 da|ax 2013-05-06 11:11:11 UTC
No error after performing the following

yum localupdate selinux-policy-3.12.1-41.fc19.noarch.rpm selinux-policy-targeted-3.12.1-41.fc19.noarch.rpm
touch /.autorelabel
setsebool -P xdm_write_home on
reboot

Thanks!

Comment 38 Miroslav Grepl 2013-05-06 11:18:21 UTC
Great, thank you for testing.

Comment 39 Richard Marko 2013-05-06 13:05:35 UTC
Description of problem:
AVC on login via lightdm

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Comment 40 William Orr 2013-05-07 04:09:02 UTC
Description of problem:
This always happens when lightdm starts.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Comment 41 Peter H. Jones 2013-05-07 13:18:28 UTC
Description of problem:
Booting Fedora-Live-XFCE-i686-19-Beta-TC3-1.iso

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.i686
type:           libreport

Comment 42 Adam Williamson 2013-05-08 17:33:49 UTC
Discussed at 2013-05-08 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Accepted as a freeze exception issue as something that would be a blocker for a blocking desktop (affects only non-blocking Xfce and MATE spins afaik).

Comment 43 Hicham HAOUARI 2013-05-09 14:44:57 UTC
Description of problem:
Normal login to mate desktop

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Comment 44 Adam Williamson 2013-05-13 17:29:59 UTC
3.12.1-42 went stable, and boblfoot commented:

"This eliminated SELinux AVC Warning at startup for me in F19-Beta-TC3 Mate Desktop."

So I think we can mark this as closed. If anyone still has this AVC in Beta TC4, please comment. Thanks!

Comment 45 klaus 2013-05-14 11:55:14 UTC
Yes, well done so far, after a couple of updates of the specific selinux packages,
no more alarming messages and getting nearer to a fedora 19 that's nice to have
and to work with. 

Only one thing, since I'm not really experienced with bugfiling reports:
The boot up process of Fedora 19 to the dm's login is pretty slow, noticeably slow. Puts me in a horrible wait state. Is there already a bug filed for this? How can I tell the developers, who put themselves in responsibility for a new Fedora 19 that makes the user happy in all aspects? Thanks.

Comment 46 Rex Dieter 2013-05-14 12:37:54 UTC
Depends on the spin and login manager used.  If still speaking in the context of lightdm, filing bugs against it would likely be the best way forward.

Comment 47 Richard Marko 2013-05-14 12:48:16 UTC
(In reply to comment #45)
> The boot up process of Fedora 19 to the dm's login is pretty slow,
> noticeably slow. Puts me in a horrible wait state. Is there already a bug
> filed for this? How can I tell the developers, who put themselves in
> responsibility for a new Fedora 19 that makes the user happy in all aspects?
> Thanks.

Make sure you are running nodebug kernel or use 'slub_debug=-' on command line when debugging performance issues.

See https://fedoraproject.org/wiki/RawhideKernelNodebug for nodebug kernels.

Comment 48 Adam Williamson 2013-05-14 16:02:43 UTC
We've been on release kernels in 19 for a while now. Klaus, sorry you're having trouble with slow startup; the first thing to look at is the output of 'systemd-analyze blame', which will show the time taken for startup of each of your services, and you should be able to see if one of them is the cause of the delay. Then you should be able to take appropriate action from there. If you need further help identifying the problem, please post on the test@ mailing list or in #fedora-qa on Freenode IRC.

Comment 49 Robert Lightfoot 2013-05-15 12:33:15 UTC
Just got an SElinux AVC Warning which traced to this bug.

Was on F19-Beta-TC4-x86_64-XFCE-DE after running "yum update" which applied 175 updates from updates-testing and then rebooting.

How do I reopen as a new similiar problem must exist for xfce.

Comment 50 Miroslav Grepl 2013-05-15 13:01:57 UTC
# rpm -q selinux-policy-targeted

Also please attach AVC msg. Thank you.

Comment 51 Robert Lightfoot 2013-05-15 19:08:50 UTC
Description of problem:
Startup following yum update

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.2-301.fc19.x86_64
type:           libreport

Comment 52 Robert Lightfoot 2013-05-15 19:11:06 UTC
[bob@localhost ~]$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-44.fc19.noarch
[bob@localhost ~]$

Comment 53 Robert Lightfoot 2013-05-15 19:12:20 UTC
Created attachment 748462 [details]
Output of AVC Message - 2013-05-15

Comment 54 Miroslav Grepl 2013-05-15 20:25:24 UTC
Please run

# setsebool -P xdm_write_home 1

Comment 55 Miroslav Grepl 2013-05-15 20:29:02 UTC

*** This bug has been marked as a duplicate of bug 963238 ***


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