Bug 677678 - systemd requires selinux-policy
Summary: systemd requires selinux-policy
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-02-15 14:54 UTC by Dominick Grift
Modified: 2011-03-12 04:42 UTC (History)
9 users (show)

Fixed In Version: systemd-20-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-12 04:42:41 UTC

Attachments (Terms of Use)

Description Dominick Grift 2011-02-15 14:54:47 UTC
Description of problem:
I could not de-install selinux-policy from my minimal rawhide installation. Seems systemd requires it.

How reproducible:
yum erase selinux-policy selinux-policy-targeted

I might be wrong but i think i saw systemd doing various things involving SELinux administration like:

relabelling from tmpfs_t dirs
relabelling to cgroup_t dirs
reading /selinux/config

I think it was setting up /sys/fs/cgroup before SELinux initialized cgroupfs.

I think i also saw systemd requiring the "process setfscreate" access vector.

Comment 1 Harald Hoyer 2011-02-16 12:00:19 UTC
If systemd requires a newer selinux-policy version, it should "Conflict" with older ones, instead of the "Requires" .

Comment 2 Dominick Grift 2011-02-17 10:44:26 UTC
Today i also noticed that systemd creates the /dev/.systemd/ask-password directory with type systemd_device_t.

First of all, i think we should keep directory objects in /dev type device_t. Like we did for /dev/.udev

Second, if we let systemd do selinux administration then we should do it consistently.

/dev/.systemd gets created with type device_t
/dev/.systemd/ask-password gets created with type systemd_device_t
/dev/.systemd/plymouth(file) gets created with type device_t
/dev/.systemd/readahead.* (file and dir) gets create with type device_t

Fedoras policy for systemd seems to have a totally different opinion:

/dev/\.systemd/ask-password-block/[^/]*		-p	gen_context(system_u:object_r:systemd_device_t,s0)

That means that systemd creates /dev/.systemd/ask-password dir with type systemd_device_t, but that if you later restore its context, that it will reset to device_t. because there is no file context specification for that directory

But all this aside. Should we let systemd be selinux aware?

If we do then we must do it consistently. Systemd creates all kinds of objects early on. For example it creates /dev/log. Yet this is created device_t currently. There are other objects, i suspect for example /dev/pts/pmtx and others.


Personally i think it may be better if we do not bother systemd with selinux.
Instead let policy/selinux worry about it.

Sure we will have to allow some domains access to device_t objects that are not labelled at some point but atleast we will be consistent.

Comment 3 Dominick Grift 2011-02-17 11:03:18 UTC
I have been told that selinux policy loading will be remove from dracut and will be moved into systemd.

I think it may be a good idea to not let systemd create objects with contexts, but to let systemd restore selinux contexts as soon as it "load_policy" hopefully systemd by then will have created all its sockets and other objects.

The after system reset contexts all should be labelled properly.

Any domain accessing any of said object before the reset will have to be allowed access to generic inherited types (like device_t)

Comment 4 Miroslav Grepl 2011-02-17 11:15:26 UTC
(In reply to comment #2)
> Today i also noticed that systemd creates the /dev/.systemd/ask-password
> directory with type systemd_device_t.

I don't agree with you. We have systemd policy for two systemd components which I believe we want to confine


I am not seeing the issue with /dev/.systemd/ask-password labeling. I am going to  investigate it.

Comment 5 Dominick Grift 2011-02-17 11:33:09 UTC
Its not in policy. systemd is hacked to create objects with contexts.

Comment 6 Miroslav Grepl 2011-02-17 12:36:23 UTC
Could you add AVC which you are seeing. Not sure why but I am not seeing this issue with

# semodule -d unconfined

Comment 7 Dominick Grift 2011-02-17 12:41:27 UTC
[    3.839403] type=1400 audit(1297936832.600:4): avc:  denied  { create } for  pid=1 comm="systemd" name="ask-password" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_device_t:s0 tclass=dir

Comment 8 Dominick Grift 2011-02-17 12:43:23 UTC
some other things that make me wonder in dmesg:

[root@localhost ~]# dmesg | grep unmapped
[    8.495057] SELinux:  Context system_u:object_r:xdm_tmp_t:s0 is not valid (left unmapped).
[    8.495269] SELinux:  Context system_u:object_r:xfs_tmp_t:s0 is not valid (left unmapped).

might not be related.

Comment 9 Dominick Grift 2011-02-17 13:04:14 UTC
Something creates stuff in my /tmp that doesnt belong there on a headless nobase fedora:


These get, i believe, created before policy is loaded because i do not have any avc denials auditing this.

Also something seems to be trying to label these or create these with labels.

Comment 10 Dominick Grift 2011-02-17 13:13:10 UTC
Whoops no there are not labelled that was a left over from fedora-selinux policy (fixfiles restore) ignores /tmp. Strange though that these labels were not reset to unlabeled_t, but i guess thats because fixfiles restore ignores /tmp

Comment 11 Lennart Poettering 2011-02-28 21:14:30 UTC
(In reply to comment #9)
> Something creates stuff in my /tmp that doesnt belong there on a headless
> nobase fedora:
> .font-unix
> .ICE-unix
> -Test-unix
> .X11-unix
> .XIM-unix

That's created by systemd-tmpfiles btw, based on /etc/tmpfiles.d/x11.conf which is currently shipped with systemd but should eventually be moved into the X11 packages I guess.

Comment 12 Lennart Poettering 2011-03-01 01:35:43 UTC
The original bug report was about systemd requiring selinux-policy, which I will fix in the 19-1 upload, following Harald's suggestion. Please clone/open seperate bugs for other issues which might be existing mentioned here.

Comment 13 Fedora Update System 2011-03-01 01:37:19 UTC
Package systemd-19-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-19-1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2011-03-01 06:48:55 UTC
systemd-19-1.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update systemd'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-19-1.fc15

Comment 15 Fedora Update System 2011-03-08 19:36:32 UTC
systemd-20-1.fc15 has been submitted as an update for Fedora 15.

Comment 16 Fedora Update System 2011-03-12 04:42:20 UTC
systemd-20-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

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