Bug 204956 - SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to /dev/nvram (unlabeled_t).
Summary: SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to /dev/nvram (unlabele...
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-01 17:51 UTC by Darwin H. Webb
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-09-02 02:21:46 UTC


Attachments (Terms of Use)

Description Darwin H. Webb 2006-09-01 17:51:42 UTC
Description of problem:
(From setroubleshoot)

SELinux denied access requested by /usr/sbin/lvm. It is not expected that this
access is required by /usr/sbin/lvm and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Version-Release number of selected component (if applicable):
selinux-policy-2.3.10-3

How reproducible:
don't know

Steps to Reproduce:
1.
2.
3.
  
Actual results:
 /dev/nvram (unlabeled_t).

Expected results:
nvram_device_t

Additional info:
ran restorecon as directed by setroubleshhot but I do not know what this means.

$ su -
Password: 
[root@Jade-38 ~]# restorecon -v /dev/nvram
[root@Jade-38 ~]# ls -halZ /dev/nvram
crw-rw----  root root system_u:object_r:nvram_device_t /dev/nvram

Comment 1 Daniel Walsh 2006-09-01 20:14:21 UTC
Did this fix the problem?  Why was /dev/nvram unlabeled_t?  This might show
symptoms of other problems like the machine is labeled incorrectly.

Dan

Comment 2 Darwin H. Webb 2006-09-01 20:41:01 UTC
I do not know if it fixed as I don't know what triggers it.
I did not get any more setroubleshoot messages within the next 5 min or so.
But I will do a relabel to make sure.

On another machine that was updated. 
1. SELinux-policy-targeted listed some restorecon set commands that were not on
the fisrt machine.
After the updates I yum installed setroubleshoot on the second machine.
(BTW: setroubleshot service is checked to start at boot but is not started at
install.)
I then open setroubleshoot gui and got a messy blank screen (probably due to the
updates.)
I did
ls -halZ /dev/nvram and is was unlabeled_t
I did
restorecon -v /dev/nvram
and got access denied. (I tried this 2 times and it triggered the AVC popup notify.)
So I closed things down and rebooted with new kernal and updates.
After log on to Gnome, in a term
ls -halZ
showed the correct label of
crw-rw----  root root system_u:object_r:nvram_device_t /dev/nvram

This could mean that the fisrt machine does need to be relabeled.
I don't know how it got mislabeled.
If anything strange occurs I'll make another note.

BTW: Thanks for setroubleshoot. It is really going to help.

Darwin


Comment 3 Daniel Walsh 2006-09-02 02:21:46 UTC
I figured out what this was, and it is not really a bug, or it will not happen
again anyways.  We changed the file context of /dev/nvram and the old one was
removed so the file context was unlabeled_t for a while.  It should be fine now.


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