Bug 919374 - /var/run not created with var_run_t leading to many boot avc's
Summary: /var/run not created with var_run_t leading to many boot avc's
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 926909 (view as bug list)
Depends On:
Blocks: F19Alpha, F19AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-03-08 09:41 UTC by Jens Petersen
Modified: 2013-04-02 16:03 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-02 16:03:32 UTC
Type: Bug


Attachments (Terms of Use)
console screenshot (14.02 KB, image/png)
2013-03-08 09:41 UTC, Jens Petersen
no flags Details
parts of dmesg output right after root login with enforcing (10.99 KB, text/plain)
2013-03-14 08:05 UTC, Jens Petersen
no flags Details
"ausearch -m avc" right after booting into new install (56.39 KB, text/plain)
2013-03-25 06:14 UTC, Jens Petersen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 917497 0 unspecified CLOSED starting rsyslog fails and loops endlessly at first boot after a netinstall of rawhide 2021-02-22 00:41:40 UTC

Internal Links: 917497

Description Jens Petersen 2013-03-08 09:41:37 UTC
Created attachment 706958 [details]
console screenshot

Description of problem:
Not sure if this is a systemd issue but I see messages
from systemd-logind when I login as root to a minimal rawhide install.

Version-Release number of selected component (if applicable):
systemd-197-2.fc19

Steps to Reproduce:
1. minimal rawhide install
2. login as root on console
  
Actual results:
2. see screenshot

Expected results:
no messages

Comment 1 Michal Schmidt 2013-03-08 10:21:57 UTC
Does it happen with SELinux in permissive mode?

Comment 2 Jens Petersen 2013-03-11 08:12:57 UTC
(In reply to comment #1)
> Does it happen with SELinux in permissive mode?

No, it doesn't.  That seems to be a workaround.

Comment 3 Michal Schmidt 2013-03-11 09:50:31 UTC
In that case please paste/attach any logged AVC denial messages. They may be in dmesg or in /var/log/audit/audit.log.

Comment 4 Jens Petersen 2013-03-14 08:05:17 UTC
Created attachment 709904 [details]
parts of dmesg output right after root login with enforcing

Tried to include only relevant parts of dmesg but I can attach
it all if it helps.

This is dmesg with enforcing enabled - currently I need to use
permissive to do anything useful with rawhide: I am not sure yet
if it is systemd's fault...

Comment 5 Michal Schmidt 2013-03-14 11:59:21 UTC
It appears you have a mislabeled /var/run symlink. Yours has context var_t, while it should be var_run_t:

$ matchpathcon /var/run
/var/run        system_u:object_r:var_run_t:s0

Fix it with "restorecon -v /var/run", or do a full relabel in case there are more mislabelled files.

Comment 6 Jens Petersen 2013-03-15 01:47:47 UTC
Well this is with a fresh minimal rawhide install. :)

Anyway thank you - let me move it over to selinux-policy then.

Comment 7 Michal Schmidt 2013-03-15 10:32:06 UTC
I don't think the bug is in selinux-policy. The policy correctly says the type should be var_run_t.

It must be a problem in how the symlink is created. /var/run belongs to the filesystem package. The package creates it in its %post scriptlet:

%post -p <lua>
posix.symlink("../run", "/var/run")
posix.symlink("../run/lock", "/var/lock")

So perhaps the scriptlet needs to explicitly fix the labels of the symlinks, or the package should switch to shipping the symlinks as is usual instead of creating them from a scriptlet. (/var/run and /var/lock have been symlinks since F15 I believe.)

Comment 8 Ondrej Vasik 2013-03-15 11:15:19 UTC
I can't have any dependency in filesystem package thus I can't run restorecon on them in post. So the only option seems to be to switch to symlinks shipping or some trigger. I'm not sure if the symlink change will resolve the issue - it may be because of the dependency timing - at the time when the symlinks are created there may be no policy which will set them the correct context or something like that.

Comment 9 Daniel Walsh 2013-03-15 15:22:39 UTC
I think anaconda used to fix these.

Can't these symlinks be shipped as part of the payload of rpm?

Comment 10 Ondrej Vasik 2013-03-15 18:57:04 UTC
They could, we'll see if this will solve the issue.

Comment 11 Jens Petersen 2013-03-18 04:18:18 UTC
So move to rpm?

Comment 12 Jens Petersen 2013-03-18 04:21:40 UTC
(Moving to F19)

Comment 13 Adam Williamson 2013-03-18 04:58:25 UTC
Is this a change between F18 and F19 anaconda - "I think anaconda used to fix these." ? Because I've done an install of F19 with F18's anaconda, and I've done an F18 minimal install and upgraded to F19, and have not had a problem booting with enforcing enabled in either case.

Comment 14 Jens Petersen 2013-03-18 08:04:02 UTC
(In reply to comment #13)
> Is this a change between F18 and F19 anaconda - "I think anaconda used to
> fix these." ?

Well I am also installing with f18 netinst.iso too.
(I think that may be the only available way currently? :)

Anyway dwalsh's suggestion to move the symlinks into rpm seems attractive.

> Because I've done an install of F19 with F18's anaconda, and
> I've done an F18 minimal install and upgraded to F19, and have not had a
> problem booting with enforcing enabled in either case.

And you don't see any avc's while booting?
When did you last do an install?

Comment 15 Adam Williamson 2013-03-18 08:06:40 UTC
Didn't notice any, no. On Saturday.

Comment 16 Jens Petersen 2013-03-18 08:56:53 UTC
Interesting - I think Tagoh doesn't seem them either
but I see them every time I install.  Perhaps there is some other
additional condition involved though can't think what it could be.

Comment 17 Jens Petersen 2013-03-18 08:59:29 UTC
(Though I think maybe Tagoh was doing an upgrade - not sure
- anyway I don't think it happens for upgrades.)

Comment 18 Ondrej Vasik 2013-03-18 09:22:55 UTC
Reason for the symlink %post lua scriptlet solution and ghost symlinks as part of filesystem rpm filelist is simple - to handle old style of common directories correctly. With moving them to payload, it will cause the conflicts in the updates (and although there is the policy about 2 Fedoras update compatibility, it still may break the distro for guys who update their in every Fedora release).

If anaconda/whatever did the relabel after installation, question is why it stopped to do so. I'll change the post scriptlet symlink solution and ghosted files, but I don't know if we want that for F19.

Comment 19 Jens Petersen 2013-03-18 09:35:22 UTC
Well it is not anaconda that changed - this is happening with F18 netinst.iso.
So maybe something else changed?

Comment 20 Rex Dieter 2013-03-18 12:35:40 UTC
fyi,

Rawhide/f20 buildroot fails now,

DEBUG util.py:264:  Error unpacking rpm package filesystem-3.2-8.fc20.x86_64
DEBUG util.py:264:  error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory

Comment 21 Ondrej Vasik 2013-03-18 13:18:31 UTC
Thanks for untagging that... reverting for the moment... so the question is - what changed? Why it works for someone and not for the others? It may be related to the https://bugzilla.redhat.com/show_bug.cgi?id=825466 ...

Maybe the best way would be to run restorecon on these two as part of firstboot?

Comment 22 Michal Schmidt 2013-03-18 13:43:37 UTC
(In reply to comment #20)
> DEBUG util.py:264:  Error unpacking rpm package filesystem-3.2-8.fc20.x86_64
> DEBUG util.py:264:  error: unpacking of archive failed on file /var/lock:
> cpio: rename failed - Is a directory

How come it was a directory?
I can see that in filesystem-3.2-8 in the spec there was:
  %dir %attr(755,root,root) /var/lock
  ...
  %attr(755,root,root) /var/run

"%dir" does not make sense to me when we want to package a symlink. Could this be what caused the buildroot breakage?
Setting the mode of a symlink is pointless.

(In reply to comment #21)
> It may be related to the https://bugzilla.redhat.com/show_bug.cgi?id=825466

By the way, in that bug I said: "Every F17 system is supposed to have /var/run as a symlink, not as a bind mount point."
Just pointing this out as it's relevant for the 2-Fedora-releases-back upgrade support rule.

Comment 23 Ondrej Vasik 2013-03-18 15:43:52 UTC
you are right, this was the remnant from the days it was there because of the ghosted /var/lock/subsys - so %dir can be dropped, let's try if this will work correctly in buildroot - I'm prepared for untag :).

Comment 24 Rex Dieter 2013-03-18 16:40:51 UTC
latest is bad too:

DEBUG util.py:264:  Error unpacking rpm package filesystem-3.2-10.fc20.i686
DEBUG util.py:264:  error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory

Comment 25 Rex Dieter 2013-03-18 16:54:00 UTC
If you haven't figured it out yet, replacing a dir with a symlink in rpm packaging is fraught with peril.  there be dragons.

Comment 26 Kay Sievers 2013-03-18 17:03:00 UTC
If any other package gets installed before filesystem.rpm, the directory will be
created by that package, not filesystem.rpm.

Here is how the stuff works in pretrans for the other links:
  http://pkgs.fedoraproject.org/cgit/filesystem.git/tree/filesystem.spec#n120

Comment 27 Ondrej Vasik 2013-03-18 17:07:10 UTC
Yes, I know, it is pretty dangerous play... Still - the question is why the symlinks created in %post had wrong context. 

I'll move that to the pretrans section, it seems to be the safest way. Thanks for suggestion, Kay.

Comment 28 Adam Williamson 2013-03-18 17:20:35 UTC
comment #21: if 'firstboot' is the answer, you are asking the wrong question.

Comment 29 Jens Petersen 2013-03-19 02:32:37 UTC
(In reply to comment #28)
> comment #21: if 'firstboot' is the answer, you are asking the wrong question.

Right that doesn't work for minimal installs anyway either.

Comment 30 Jens Petersen 2013-03-19 04:29:41 UTC
I am a bit naive about ordering of rpm install and script transactions under yum/anaconda.

Would all %post scripts not be run after all packages have been installed?
If so then couldn't "restorecon" be run in filesystem's %post if available
without explicit requires(post)?
I could be completely wrong here, but thought this might help?

Comment 31 Adam Williamson 2013-03-19 06:03:45 UTC
No. %post scripts run as soon as that particular package's install transaction is done.

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering

I'm not sure if %posttrans is what you're looking for, or if even that ultimately still only runs after one package is installed and before the next.

Comment 32 Ondrej Vasik 2013-03-19 07:42:54 UTC
Requires(post) will not work here, it will make the dependency loop with uncertain behaviour.
I'll try the %pretrans approach suggested by Kay - another option might be %triggerin on policycoreutils, so everytime policoreutils is installed/updated, restorecon on these two would be called.

Comment 33 Adam Williamson 2013-03-20 16:42:08 UTC
I've done a bunch of F19 installs and live image composes in the last few days, and have not seen this problem (though I've seen plenty of others). I am not confident we should be rushing to 'fix' it.

Comment 34 Adam Williamson 2013-03-20 16:46:47 UTC
Discussed at 2013-03-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-20/f19alpha-blocker-review-2.2013-03-20-16.00.log.txt . We agreed to delay any decision on this until more F19 testing is going on; as stated above I have not seen this, other testers so far have either been disabling selinux or not getting far enough to see this.

Comment 35 Jens Petersen 2013-03-25 05:28:51 UTC
I still see this today doing a fresh F19 minimal netinst
(from F18 netinst.iso: wish I had a working F19 netinst.iso).

Symptoms:
- console login is slow.
- eth0 is down
- some boot failure messages from systemd
- /var/run has context var_t

Can anyone else reproduce this?

Should be easily reproducible:

This is how I install:
0. Create guest in virt-manager (running on F18 x86_64 host)
1. select F18 netinst iso as boot iso
2. 5GB HD, 1GB RAM
3. Boot with repo=http://download.fedoraproject.org/pub/fedora/linux/development/19/x86_64/os/
 (you may prefer to specific the mirror explicitly)
4. Select Minimal install, autopartitioning, etc
5. start install (set root passwd)
6. reboot into new minimal guest
7. run "ausearch -m avc -ts today" to see avc's

Comment 36 Jens Petersen 2013-03-25 06:01:05 UTC
+ Also my install is in en_US.utf8 and Tokyo timezone.


I just did another install to recheck:

# ls -lZd /run /var/run
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run
lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/run -> ../run

but note that:
# ls -lZd /run /var/run/
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run/
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run/run/

so please be careful when checking the context of the symlink.

Comment 37 Jens Petersen 2013-03-25 06:14:36 UTC
Created attachment 715856 [details]
"ausearch -m avc" right after booting into new install

(console login takes about 20s)

Comment 38 Daniel Walsh 2013-03-25 14:44:14 UTC
selinux-policy package also has a restorecon /var/run in it.

Comment 39 Jens Petersen 2013-03-26 02:39:33 UTC
(In reply to comment #38)
> selinux-policy package also has a restorecon /var/run in it.

But neither selinux-policy-3.12.1-23.fc19.noarch nor
selinux-policy-targeted-3.12.1-23.fc19 do.
Perhaps one of them should?

Comment 40 Jens Petersen 2013-03-26 02:44:30 UTC
(In reply to comment #39)
> But neither selinux-policy-3.12.1-23.fc19.noarch nor
> selinux-policy-targeted-3.12.1-23.fc19 do.
> Perhaps one of them should?

Sorry seems I can't grep, I take that back:

selinux-policy-targeted.noarch has

/sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* /etc/*shadow* 2> /dev/null;

Comment 41 Jens Petersen 2013-03-26 02:55:18 UTC
Anyway for minimal install, filesystem is package 3 out of 238
and selinux-policy-targeted is 228 out of 238 installed.
This is all very mysterious...

I looked at the packages installed after selinux-policy-targeted
but none of their scripts seem to touch /var/run AFAICT.

Comment 42 Jens Petersen 2013-03-26 02:59:04 UTC
Indeed if I "yum reinstall selinux-policy-targeted" the context
of /var/run changes to var_run_t.

Comment 43 Jens Petersen 2013-03-26 03:03:57 UTC
(In reply to comment #42)
> Indeed if I "yum reinstall selinux-policy-targeted" the context
> of /var/run changes to var_run_t.

which also fixes the long (20s+) login delay, brings up eth0,
and allows login to run on other kernel vconsoles.

Comment 44 Jens Petersen 2013-03-26 03:06:18 UTC
Is noone else really seeing this??

Comment 45 Daniel Walsh 2013-03-26 17:22:21 UTC
No I have seen others report this also.  But the selinux-policy package usually clears it up.

Comment 46 Daniel Walsh 2013-03-26 17:27:51 UTC
Since there is no real security difference between reading var_run_t symlinks and var_t symlinks, I have changed the policy to allow domains that need to use /run content to read either.

7ce7dc0be7cb4f7b63cc2c9d8957b79eee0b7bb7 in git fixes this.

Comment 47 Daniel Walsh 2013-03-26 20:02:58 UTC
*** Bug 926909 has been marked as a duplicate of this bug. ***

Comment 48 Jens Petersen 2013-03-27 01:23:32 UTC
(In reply to comment #46)
> Since there is no real security difference between reading var_run_t
> symlinks and var_t symlinks, I have changed the policy to allow domains that
> need to use /run content to read either.

Thanks - sounds good

Actually I was wondering when it makes sense to differentiate
the security context of a dir symlink and its target like this?
(eg /path/to/symlink and /path/to/symlink/).

Comment 49 Jens Petersen 2013-03-27 02:49:52 UTC
As far as I can tell selinux-policy-targeted %post is failing to
set var_run_t for /var/run when installing so I am reassigning to selinux-policy.
(At least for F18 selinux-policy-targeted %post did set the context
correctly AFAICT.)


Here is a diff of the relevant changes between the f18 and f19 %post scripts:

--- selinux-policy-targeted-3.11.1-86.fc18.noarch.post	2013-03-27 11:23:31.309925412 +0900
+++ selinux-policy-targeted-3.12.1-23.fc19.noarch.post	2013-03-27 11:23:01.408948985 +0900
@@ -20,8 +20,8 @@
@@ -28,6 +28,6 @@
 [ "${SELINUXTYPE}" == "targeted" ] && selinuxenabled && load_policy; 
 if [ $1 -eq 1 ]; then 
-   /sbin/restorecon -R /root /var/log /var/run 2> /dev/null; 
+   /sbin/restorecon -R /root /var/log /run 2> /dev/null; 
 else 
 
 . /etc/selinux/config; 
@@ -35,7 +35,7 @@
 /usr/sbin/selinuxenabled; 
 if [ $? = 0  -a "${SELINUXTYPE}" = targeted -a -f ${FILE_CONTEXT}.pre ]; then 
      /sbin/fixfiles -C ${FILE_CONTEXT}.pre restore 2> /dev/null; 
-     /sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* 2> /dev/null; 
      rm -f ${FILE_CONTEXT}.pre; 
-     restorecon -R /home/*/.cache /home/*/.config 2> /dev/null; 
-fi;fi;exit 0
+fi; 
+/sbin/restorecon -e /run/media -R /root /var/log /var/run /etc/passwd* /etc/group* /etc/*shadow* 2> /dev/null; 
+/sbin/restorecon -R /home/*/.cache /home/*/.config 2> /dev/null;fi;exit 0


So from my reading of selinux-policy-targeted-3.12.1-23.fc19.noarch.post
it only does restorecon on /run when newly installing itself and does
restorecon on /var/run updating.

Comment 50 Miroslav Grepl 2013-03-27 14:00:52 UTC
Fixed in -24.fc19

Comment 51 Adam Williamson 2013-03-27 17:42:22 UTC
Discussed at 2013-03-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-27/f19alpha-blocker-review-3.2013-03-27-16.01.log.txt . Many people do seem to be hitting this, so we're going to agree that I'm on crack, and accept this as a blocker per criterion "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."

Comment 52 Adam Williamson 2013-03-28 20:20:49 UTC
-24 should be in the repos now, setting to ON_QA. could people please re-test with -24 if plausible for your reproducer? I'll try and ensure -24 is in TC3 for reproducers relying on TC images.

Comment 53 Jens Petersen 2013-03-29 03:13:35 UTC
Yes -24 fixes the problem for me - I meant to post that yesterday.
I am keen also to retest installing with -25
which may have additional changes for this.

Comment 54 Jens Petersen 2013-03-29 08:36:50 UTC
Also F19 Alpha TC3 minimal netinstall looks good.

(/var/run is still var_t but that no longer invokes avc's -
I still hope that -25 will have var_run_t though I don't
claim to understand fully the underlying subtleties there.)

Comment 55 Jens Petersen 2013-04-01 03:01:18 UTC
I think you can ignore my comments about -25.
I am pretty sure the AVC's are fixed now.
Moving to VERIFIED.

It still seems to me though it would be more consistent to use only var_run_t  security context for the /var/run symlink.

Comment 56 Adam Williamson 2013-04-02 16:03:32 UTC
If it's fixed in -25, we can close it.


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