Bug 204956 - SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to /dev/nvram (unlabeled_t).
SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to /dev/nvram (unlabele...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-01 13:51 EDT by Darwin H. Webb
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-01 22:21:46 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)

  None (edit)
Description Darwin H. Webb 2006-09-01 13:51:42 EDT
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 16:14:21 EDT
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 16:41:01 EDT
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-01 22:21:46 EDT
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.