Description of problem: Following denials are emitted to the kernel log during boot: [ 12.180338] type=1400 audit(1304411954.843:4): avc: denied { read } for pid=473 comm="systemd-tmpfile" name="lock" dev=vda3 ino=390413 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file [ 12.302139] type=1400 audit(1304411954.965:5): avc: denied { read } for pid=473 comm="systemd-tmpfile" name="lock" dev=vda3 ino=390413 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file Version-Release number of selected component (if applicable): # rpm -q selinux-policy-targeted selinux-policy-targeted-3.9.16-21.fc15.noarch How reproducible: always Steps to Reproduce: 1. boot system Actual results: Denials in the kernel log. Expected results: No denials. Additional info: I'm not sure if this AVC denial should be "dontaudited" (and systemd-tmpfile will read only /run) or systemd-tmpfile should be allowed to read /var/lock, which is: # ll -dZ /var/lock lrwxrwxrwx. root root system_u:object_r:var_t:s0 /var/lock -> ../run/lock
Lennart, do you think systemd-tmpfile should be allowed to read /var/lock symlink or it should rather read only /run/lock directory? Thank you in advance for your response.
Adam, is this a fresh install? What does # restorecon -R -v /var # ll -dZ /var/lock
(In reply to comment #2) > Adam, > is this a fresh install? Yes it is. I grabbed F15 beta netinst ISO and installed minimal set of packages (current packages from F15 updates-testing was pulled as well). > What does > > # restorecon -R -v /var > > # ll -dZ /var/lock Restorecon fixed the labelling of the /var/lock. So it seems something (I think it is the filesystem package) creates the /var/lock symlink and doesn't call restorecon on it after it is created. Reassigning to filesystem for further inspection.
we can't call restorecon on it - think about the dependencies ...
(In reply to comment #4) > we can't call restorecon on it - think about the dependencies ... Good point. I remember I faced similar issue some time ago with bind-chroot package (some files needed to be restorecon-ed after installation of the package) and after discussion I solved it via rpm's %posttrans scriptlet. Something like this might work in this case (not tested): %posttrans if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then [ -x /sbin/restorecon ] && /sbin/restorecon /var/lock > /dev/null 2>&1; fi; :; What do you think about solution written above? Another solution is to leave /var/lock mislabelled and simply don't audit the AVC denial.
if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then Is not necessary since restorecon does this check itself. I think this should probably be done by anaconda. Anaconda has a whole list of files that are created before policy gets put down tat it runs restorecon at the end of installation.
*** Bug 698223 has been marked as a duplicate of this bug. ***
*** Bug 708967 has been marked as a duplicate of this bug. ***