Bug 504266 - Xorg fails to start with selinux in enforcing mode
Xorg fails to start with selinux in enforcing mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-05 04:50 EDT by Mace Moneta
Modified: 2009-06-20 07:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-20 07:26:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log (10.06 KB, text/plain)
2009-06-05 04:50 EDT, Mace Moneta
no flags Details
dmesg (49.07 KB, text/plain)
2009-06-05 13:26 EDT, Mace Moneta
no flags Details
messages (305.44 KB, text/plain)
2009-06-05 13:26 EDT, Mace Moneta
no flags Details
Screenshot of adding an attachment (180.02 KB, image/png)
2009-06-05 15:57 EDT, Mace Moneta
no flags Details
/var/log/messages (455.54 KB, text/plain)
2009-06-06 14:07 EDT, Mace Moneta
no flags Details

  None (edit)
Description Mace Moneta 2009-06-05 04:50:29 EDT
Created attachment 346618 [details]
Xorg.0.log

Description of problem:

After applying the updates-testing updates, xorg would no longer start.  The Xorg.0.log reports:

Fatal server error:
xf86MapVidMem: failed to open /dev/mem (Permission denied)

I don't know if this is an selinux policy issue or an X server issue (both were updated).  Setting selinux to permissive allows X to start normally.  There are no audits.

Version-Release number of selected component (if applicable):

libX11-1.2.1-2.fc11.x86_64
xorg-x11-server-common-1.6.1.901-2.fc11.x86_64
xorg-x11-server-Xorg-1.6.1.901-2.fc11.x86_64
selinux-policy-targeted-3.6.12-45.fc11.noarch
selinux-policy-3.6.12-45.fc11.noarch

How reproducible:

Always

Steps to Reproduce:
1.Update to updates-testing
2.Reboot
3.
  
Actual results:

X fails to start

Expected results:

X starts normally

Additional info: I'm using the Intel driver (G45/X4500).  There is no xorg.conf.  KMS is disabled with nomodeset.
Comment 1 Matěj Cepl 2009-06-05 09:17:55 EDT
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

1) Could we get also /var/log/audit/audit.log attached to this issue (please, check "Private attachment" when attaching it)?
2) what is the security context of /dev/mem on your computer? I.e., could we get output of command

ls -lZ /dev/mem
3) /var/log/messages and /var/log/dmesg could be also relevant. Please attach them as well.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Mace Moneta 2009-06-05 13:26:06 EDT
Created attachment 346688 [details]
dmesg
Comment 3 Mace Moneta 2009-06-05 13:26:52 EDT
Created attachment 346689 [details]
messages
Comment 4 Mace Moneta 2009-06-05 13:28:21 EDT
$ ls -lZ /dev/mem
crw-r-----. root kmem system_u:object_r:memory_device_t:s0 /dev/mem

I haven't attached the audit log, because I can't find any private attachment option when adding an attachment.
Comment 5 Matěj Cepl 2009-06-05 15:45:39 EDT
(In reply to comment #4)
> $ ls -lZ /dev/mem
> crw-r-----. root kmem system_u:object_r:memory_device_t:s0 /dev/mem

This is correct.

> I haven't attached the audit log, because I can't find any private attachment
> option when adding an attachment.  

In the page where you add attachment is (below the comment box) checkbox "Private".
Comment 6 Mace Moneta 2009-06-05 15:57:04 EDT
Created attachment 346710 [details]
Screenshot of adding an attachment

There's no private option here.
Comment 7 Matěj Cepl 2009-06-05 16:04:02 EDT
(In reply to comment #6)
> Created an attachment (id=346710) [details]
> Screenshot of adding an attachment
> 
> There's no private option here.  

Sorry, then send it to me (my email is mcepl at redhat domain). Thanks.
Comment 9 Matěj Cepl 2009-06-05 17:57:45 EDT
(once more, just that you can read it)

Actually this doesn't look like a SELinux problem:

bradford:~$ grep denied audit.log 
type=AVC msg=audit(1244157410.916:33926): avc:  denied  { write } for  pid=5709
comm="crontab" path="/root/crontab.save" dev=dm-0 ino=275402
scontext=unconfined_u:unconfined_r:admin_crontab_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1244157477.249:33930): avc:  denied  { write } for  pid=8350
comm="crontab" path="/root/crontab.save" dev=dm-0 ino=275402
scontext=unconfined_u:unconfined_r:admin_crontab_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
bradford:~$ 

And I don't think cron has anything to do with starting Xorg.
Comment 10 Matěj Cepl 2009-06-05 17:58:59 EDT
Dan, what do you think?
Comment 11 Mace Moneta 2009-06-05 18:30:23 EDT
Those denied messages are from trying to issue:

crontab -l > crontab.save

not from starting X.  I resolved that particular issue by doing: 

crontab -l | cat > crontab.save
Comment 12 Daniel Walsh 2009-06-06 07:01:03 EDT
This looks like you have some kind of labeling problem.

fixfiles restore 

Should cleanup the labeling

Readahead in your log files was complaining about gdm and /usr/bin/Xorg being unlabled_t which means the policy does not understand the labels on these files.

Was this an upgraded system?
Comment 13 Mace Moneta 2009-06-06 14:07:38 EDT
Created attachment 346758 [details]
/var/log/messages

It was a clean install with the F11 Preview. I restored some files, and then ran restorecon on them.  Everything was running fine, with periodic reboots for new kernels until I applied the updates testing maintenance yesterday.

I ran fixfiles restore and re-enabled enforcing mode.  It's working now, so there was a labeling problem.  I'm just concerned about the origin of that problem.

I've attached a new /var/log/messages.  At 'Jun  6 13:33:52' you can see the relabeling that occurred. I rebooted afterwards with selinux in enforcing.  The tty sessions failed to start, which is new, but I have yet to look into that.
Comment 14 Adam Jackson 2009-06-19 15:57:02 EDT
Not an X bug, by the sound of it.
Comment 15 Daniel Walsh 2009-06-20 07:26:05 EDT
Looks fine now,  Might have just been a bug in one of the beta selinux-policy packages.  Sorry about that.  If it happens in the released version please reopen this bugzilla.

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