Description of problem: 'Authorization Indicator' (gold badge in notification area applet indicating that a normal user has root access) will not appear when SELinux mode is set to 'Enforcing', but does appear when mode is 'Permissive'. Version-Release number of selected component (if applicable): Not sure which module is causing the issue, but here is package info on some candidates: Notification Area applet: 2.20.3 SELinux policy: 3.0.8 GNOME: 2.20.3 How reproducible: Need an F8 installation using GNOME with SELinux mode set to Enforcing. Also need a normal (non-root) account. Steps to Reproduce: 1. Log in to normal account. 2. Start up 'Users and Groups' application under System/Administration menu. 3. Enter root password and verify that the application starts up. Observe that there is no gold badge in the notification area to allow you to forget authorization. 4. Start up SELinux Management application under Applications/System Tools menu. 5. Change 'Current Enforcing Mode' from 'Enforcing' to 'Permissive'. The gold badge will appear almost immediately in the notification area. Change the enforcing mode back to 'Enforcing' and the badge will disappear. When the badge is visible, you can forget authorization to clear the root access. Actual results: Gold badge not always visible. This will cause root access to remain until it times out. Expected results: Expect gold badge to always be visible when root access is activated so that user is aware of it and also so that the user can 'forget' the root authorization. Additional info: I have 3 different 64-bit F8 installs and the behavior is the same in each one. Two were clean installs of F8 and the other was an upgrade of F7.
/sbin/pam_timestamp_check is not allowed to access /var/run/utmp. This is what auditallow produces: allow pam_t initrc_var_run_t:file { read write lock }; but perhaps /var/run/utmp should have a different context?
Does it work if you just allow read and lock? WHich is what I will add in 94. You can allow this for now by executing # audit2allow -M mypol -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.0.8-94.fc8
Yes, {read lock} is enough.
Right after the first three comments were posted, I created a custom policy module to implement the {read lock} permissions and it worked fine. However, I just removed that custom policy module and pulled down selinux-policy-3.0.8-95.fc8 from updates-testing and this issue is not fixed as of that release. If I reapply my custom policy module, it again works correctly. Please advise.
Please attach the avc messages you are seeing without your fix applied?
Where would I find those? I don't get any SE alerts (and never have even before I reported the bug). I'm curious where Miloslav got the info on what the problem was. After removing my policy module, I've watched changes to /var/log/audit/audit.log as I activated root access in a normal account and the badge *did not* appear -- there are no USER_AVC messages. There is nothing in secure or messages either that looks abnormal. I'm a bit of a noob with this audit stuff, so please give a little more detail on how to capture the data you need...thanks! BTW, here is the policy I created (that works) based on the first three comments...are you sure selinux-policy-3.0.8-94.fc8 and later has this? require { type pam_t; type initrc_var_run_t; class file {read lock}; } allow pam_t initrc_var_run_t:file {read lock};
I was just poking around updates-testing to see if there was a new version of selinux-policy. There wasn't, but I noticed selinux-policy-targeted-3.0.8-95.fc8 was out there and I had not updated to it. Once I updated my selinux-policy-targeted package from updates-testing, the 'badge' now appears as it should (yes, I made sure my policy module was removed). Originally, I had only updated selinux-policy as that was all that was mentioned above. I guess I needed to update both of them. Looks like this issue has been corrected. Thanks!
Question: I noticed that the Fedora 9 Beta has this problem as well. Will the fix implemented here eventually find it's way into the F9 packages or does another bug need to be opened? Thanks, Patrick
All fixes go into all packages. If I see a bug report against Any release I try to fix it in all releases that it would effect.