Bug 701575 - SELinux prevents systemd-tmpfile to read /var/lock
SELinux prevents systemd-tmpfile to read /var/lock
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 698223 708967 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-03 05:08 EDT by Adam Tkac
Modified: 2011-06-01 16:45 EDT (History)
9 users (show)

See Also:
Fixed In Version: anaconda-16.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-17 15:59:47 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 Adam Tkac 2011-05-03 05:08:18 EDT
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
Comment 1 Adam Tkac 2011-05-03 05:12:26 EDT
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.
Comment 2 Miroslav Grepl 2011-05-03 07:35:39 EDT
Adam,
is this a fresh install?

What does

# restorecon -R -v /var

# ll -dZ /var/lock
Comment 3 Adam Tkac 2011-05-03 09:48:41 EDT
(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.
Comment 4 Ondrej Vasik 2011-05-03 11:29:00 EDT
we can't call restorecon on it - think about the dependencies ...
Comment 5 Adam Tkac 2011-05-03 11:41:10 EDT
(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.
Comment 6 Daniel Walsh 2011-05-03 12:06:57 EDT
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.
Comment 7 Miroslav Grepl 2011-05-22 14:40:56 EDT
*** Bug 698223 has been marked as a duplicate of this bug. ***
Comment 8 Nathan Kinder 2011-06-01 16:45:34 EDT
*** Bug 708967 has been marked as a duplicate of this bug. ***

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