On 06/30/2016 06:13 PM, Lennart Poettering wrote: > On Thu, 30.06.16 10:45, Simo Sorce (simo@xxxxxxxxxx) 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx