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
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
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
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.