On 06/30/2016 06:13 PM, Lennart Poettering wrote:
On Thu, 30.06.16 10:45, Simo Sorce (simo(a)redhat.com) wrote:
>>> Insert your idea here …
>>
>> Do it the same way `dnf system-upgrade` works. The requirements (having local
filesystem read- and writable) are quite similar. Or the way PackageKit's system
upgrade works…
>> probably the same as (b) though…
>
> This s something I agree with, the system should have an autorelabel
> target that is one-shot just like the system upgrades, and it should
> bring up really the minimal system required to boot and mount the
> filesystem to be relabeled and nothing else, it should work in
> permissive mode and possibly with auditing enabled.
Yeah, I agree. My suggestion would be for SELinux to provide a systemd
"Generator" tool (see systemd.generator(7) for details) that checks
for the auorelabel flag file or kernel comand line option and then
diverts the boot into a special relabel target that pulls in
local-fs.target and very little else, then does its relabelling and
reboots again. During all of this selinux should be in permissive
mode, after all the labels are generally borked if you boot into this
mode, and hence not suitable for making security decisions.
Pretty much all of that should live in some selinux package I figure.
I like the idea that the relabeling will be isolated in a special
target. And we've recently moved fedora-selinux.service to
policycoreutils so it could live there.
However, it won't probably fix the following problems:
(2) when a generator file was mislabeled it could not be run by systemd
as systemd can't read fedora-relabel unit file now
Unless we want to loosen the policy to allow systemd read file with any
file context, it will be up to a administrator to set a permissive mode
via the kernel command line
(5) the relabeling service will still need to have StandardInput=tty to
provide a possibility to relabel a system manually
Petr
--
Petr Lautrbach