Re: Fixing /.autorelabel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/30/2016 09:52 PM, Richard W.M. Jones wrote:
> On Thu, Jun 30, 2016 at 09:23:45PM +0200, Petr Lautrbach wrote:
>> 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
> 
> I think Lennart's idea still works because he is suggesting that
> SELinux is in Permissive mode during this time.

SELinux policy is loaded in systemd on very beginning so unless it's set
to be permissive in the config file or on the kernel command line, a
system is in enforcing mode until something - in this case a generator
or an service generated by the generator - changes the mode.


Petr
-- 
Petr Lautrbach


Attachment: signature.asc
Description: OpenPGP digital signature

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux