Bug 677678

If systemd requires a newer selinux-policy version, it should "Conflict" with older ones, instead of the "Requires" .

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.

setrans_var_run_t
xdm_tmp_t
xfs_tmp_t

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.

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)

(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

/bin/systemd-tty-ask-password-agent         
/usr/bin/systemd-gnome-ask-password-agent  
/lib/systemd/systemd-tmpfiles              

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

Its not in policy. systemd is hacked to create objects with contexts.

Could you add AVC which you are seeing. Not sure why but I am not seeing this issue with

# semodule -d unconfined

[    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

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.

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

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.

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

(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.

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.

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:
https://admin.fedoraproject.org/updates/systemd-19-1.fc15
then log in and leave karma (feedback).

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

systemd-20-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-20-1.fc15

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.