This tracker is to keep track of all bugs for systemd and SELinux support.
Created attachment 419244 [details]
I'm unable to install SystemD on hardened/linux/amd64/selinux. My emerge info is above.
SystemD is still blocked by all SELinux profiles: http://bit.ly/1MfIcoN
According to the wiki, it should be possible to install SystemD on a SELinux profile: https://wiki.gentoo.org/wiki/SELinux/FAQ#Can_I_use_SELinux_with_systemd.3F
Can we get the SELinux package.mask updated to remove SystemD or at least update the wiki detailing _why_ it can't be installed?
Huh, looks like an incorrect statement on the wiki to me (blame: https://wiki.gentoo.org/index.php?title=SELinux/FAQ&diff=prev&oldid=361810 ), likely an edit without actually testing it. Last time I tested it, the system didn't boot in enforce mode due to missing policy. For it to work, the policy mentioned in Comment 1 would have to be integrated, and I'd expect this very bug entry to be updated once that is done (or, indeed, if the change was in progress).
I'm happy to help test with that if any assistance is required. Sooner it gets merged, the sooner I can start using Gentoo :)
The systemd policies have been merged in to 2.20141203-r10 which I just stabilized. I am not going to lift the mask yet because I have not had the time to fully test it.
(In reply to Dainius Masiliūnas from comment #5)
> Huh, looks like an incorrect statement on the wiki to me
Weird, I have no idea who edited that. I did not intend to change that till it was fully tested to be working.
(In reply to Naftuli Tzvi Kay from comment #6)
> I'm happy to help test with that if any assistance is required.
I'd love for as many people to help testing as possible. You can negate the mask locally on your machine in /etc/portage/profile/package.use.mask (put a - in front) and /etc/portage/package.unmask (just put the packages in here).
It *should* install and all work, our gentoo policy is fairly close to upstream and they tested it but I dont want to lift it until I am sure. I had too many reports of people failing to boot and getting locked out so Im going to err on the side of caution.
If you test it and there are any issues, please open new bugs and make them block this one.
Wanted to try this out, but got hit by #568754.
Mea culpa! Sorry to everyone for possible inconvenience, non booting machines etc.! :-(
I wrote that wiki FAQ section primarily as a fix for the ”systemd” writing and with only a small glimpse onto this bug (with two RESOLVED deps). After I stumbled onto this bug here some minutes ago I rewrote the FAQ entry again:
SELinux + systemd tests will follow.
What are the exact steps to unmask systemd (and dbus and policy) with selinux under the hardened amd64 profile? (sorry but not that familiar with all the portage details), so I can test systemd+selinux?
(In reply to Nelson from comment #10)
> What are the exact steps to unmask systemd (and dbus and policy) with
> selinux under the hardened amd64 profile? (sorry but not that familiar with
> all the portage details), so I can test systemd+selinux?
I went to the steps the SELinux installing article (in wiki.gentoo.org) suggests and took a look for everything I had to unmask at every small step.
Currently I have
<path to tree>/profiles/features/selinux/package.mask (symlinked or copied to /etc/portage/package.unmask
The -systemd masks via profile’s package.use.mask are a bit more ugly (there is only this ’negative syntax’):
$ cat /etc/portage/profile/package.use.mask/SELinux-systemd:
# negate the USE masking.
# see https://bugs.gentoo.org/show_bug.cgi?id=528674
As of 2016-10-17, 8:15 pm UTC+2, *can’t* boot systemd with selinux in enforcing mode and strict policy module (systemd-udev and -logind and some other fail to start).
Yeay, works for me! (pun intended ;)
I can boot into enforcing and strict SELinux now (and start X, play music and use my GPU). However, I had to put these domains into permissive mode:
That was more or less audit2allow copy’n’pasted; there might be some domains I will able to remove from this list, too.
I hope this will help some other testers.
Created attachment 464016 [details, diff]
I have managed to get systemd up in enforced mode. Of course several changes to the policy were needed including adding some more types. I've committed all changes into Git. The repository is available on GitHub (https://github.com/KrissN/hardened-refpolicy).
In addition to policy changes some minor tweaks were needed to systemd itself:
- The systemd-tmpfiles service tries to forcibly update contexts of files that already exist and have the right context. The patch makes systemd-tmpfiles check if the existing file has the proper context already and avoid changing it in such case.
- There is a chicken-and-egg problem with the root cgroup filesystem. It is mounted early during boot in rw mode. Next subsequent cgroup filesystems are mounted and finally the root of the cgroup filesystem is remounted read-only. At this stage the policy is not loaded so it's impossible to set proper contexts. Once the policy is loaded later it is impossible to reset the contexts as the filesystem is now read-only. The patch adds a workaround - once the SELinux policy is loaded the cgroup root filesystem is temporarily remounted read-write only to set proper contexts and then remounted back in read-only mode.
The patch introducing the changes is attached.
The changes work on my pretty minimal installation and I'm sure there are more changes to be done depending on individually enabled set of services. I hope however that they can be used as a baseline for further improvements.
(In reply to Krzysztof Nowicki from comment #13)
> I have managed to get systemd up in enforced mode. Of course several changes
> to the policy were needed including adding some more types. I've committed
> all changes into Git. The repository is available on GitHub
Hey! this is pretty awesome! Would you be up for sending these patches upstream to refpolicy? (the mailing list is http://oss.tresys.com/mailman/listinfo/refpolicy)
Russell Coker from debian has also been adding a ton of stuff lately for systemd so i'd be great if you could coordinate a bit so the best stuff gets merged in :).
Git this in today to fix some more denials related to cgroups - should be out in 263: https://github.com/systemd/systemd/pull/7496
Of course the above needs an accompanying patch to the policy in order to work.
Overall there is progress - systemd is able to start to a local shell with current reference policy. There are some errors related to systemd-tmpfiles for Gentoo-specific files. I would also not expect shutdown/reboot to work in enforcing mode.
More patches to both upstream and Gentoo policy are underway.
I want to test this also, but how do I remove the mask for:
- sec-policy/selinux-base-policy-9999::gentoo (masked by: missing keyword)
Adding an unmask for `sec-policy/selinux-base-policy` didn't help.
I'm new to Gentoo, but not new to systemd or selinux.
(In reply to maxmodulo from comment #16)
> I want to test this also, but how do I remove the mask for:
> - sec-policy/selinux-base-policy-9999::gentoo (masked by: missing keyword)
> Adding an unmask for `sec-policy/selinux-base-policy` didn't help.
> I'm new to Gentoo, but not new to systemd or selinux.
This is actually a keyword (see "missing keyword" in the error message you pasted), so an entry to package.accept_keywords is necessary instead:
echo "=sec-policy/selinux-base-policy-9999 **" >> /etc/portage/package.accept_keywords
For more details see https://wiki.gentoo.org/wiki/Knowledge_Base:Accepting_a_keyword_for_a_single_package.
By the way: For future questions about portage configuration the forum, the plenty IRC channels on freenode (#gentoo-hardened), and the mailing lists might better places than bug reports. :)
(In reply to Nils Freydank from comment #17)
> (In reply to maxmodulo from comment #16)
> > I want to test this also, but how do I remove the mask for:
> > - sec-policy/selinux-base-policy-9999::gentoo (masked by: missing keyword)
> > Adding an unmask for `sec-policy/selinux-base-policy` didn't help.
> > I'm new to Gentoo, but not new to systemd or selinux.
> This is actually a keyword (see "missing keyword" in the error message you
> pasted), so an entry to package.accept_keywords is necessary instead:
> echo "=sec-policy/selinux-base-policy-9999 **" >>
> For more details see
> By the way: For future questions about portage configuration the forum, the
> plenty IRC channels on freenode (#gentoo-hardened), and the mailing lists
> might better places than bug reports. :)
> Best regards,
Understood, Nils. Many thanks for your kind reply. :)
With planned upstream changes in gnome-3.34 using systemd --user for session management, stabilizing SELinux + systemd becomes more urgent.
Links to relevant updates and upstream bugs:
* https://github.com/systemd/systemd/issues/1941 [systemd --user + selinux discussion]
As another interested user, I'm wondering what the progress is in ensuring that systemd and SELinux can play well together. It's disheartening to see the last comment on this bug is nearly NINE MONTHS old
Have no fear - I haven't forgotten about the topic. Due to family commitments the progres has gone very slow.
Recently - after a long time - I came back to the subject. Unfortunately I have noticed, that the Gentoo SELinux policy development has stopped. Luckily I was able to switch to upstream reference policy and after doing some minor tweaks to the ebuilds I was able to install it.
Surprisingly there were not too many problems. The system did not start in enforcing mode, but after doing some patching I was able to get it to work. This work is of course not finished, but I'm happy with the progress so far.
Patches will be heading upstream soon.
My only concern is lack of development on Gentoo SELinux policy, but regardless of what happens, upstream changes will be merged to it eventually.
Any time estimates? I know that other distros have SELinux running fine with Systemd. And on my Gentoo box (my PREFERRED Distro!) I really miss having Systemd.