Re: monolithic policy on a volatile root

[Petr Lautrbach <plautrba@redhat.com>]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Fri, Aug 2, 2024 at 4:27 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>
>> I think this question was already asked but I could not find the
>> discussion.
>>
>> What would be the challenges to support a monolitic policy on a volatile
>> root?
>>
>> In a volatile root scenario there is only a non-volatile readonly
>> /usr. Would it be possible to teach libselinux that if there is a
>> /usr/selinux and not a /etc/selinux and/or /var/lib/selinux that it would
>> use that instead?
>>
>> The challenge I am currently facing with systemd.volatile=yes is that
>> when the policy is loaded from initramfs that systemd-tmpfiles (and
>> systemd-sysusers) cannot properly populate root from /usr/share/factory
>> (or created) because they rely on libselinux,get/setfilecon and thus on
>> /etc/selinux/contexts/files. There is a slight chicken and egg situation there.
>>
>> Often times its not a probable because one can do with automatic type
>> transitions but some of these files get created atomically (/etc/passwd
>> and /etc/shadow for example) and not to mention that these libselinux
>> linked components might get confused and noisy if selinux is enabled and
>> enforcing but there is no /etc/selinux.
>>
>> Duplicating policy in initramfs and /etc, /var/lib would invite
>> inconsistencies and is not feasible but if the policy is readonly and
>> thus monolitic then this might be feasible if it is not too
>> ugly. Actually in such a scenario we would probably not need a policy in
>> initramfs at all since systemd would just load it from /usr instead of /etc.
>
> I've seen a similar concern raised previously even for modular/managed policy.
> It's all just software so I don't think it would be hard to modify
> libselinux to fall back to /usr/selinux if there is no file in
> /etc/selinux; it just requires someone to write a patch for it. May
> have policy implications (i.e. anything that currently accesses
> /etc/selinux now also may need search access to usr_t) but that's
> pretty common anyway.

Using /usr for factory policy files has been on my todo list for a long
time.

Files from /usr/etc/selinux and /usr/lib/selinux would be used as
default but they would be overridden by files in /etc/selinux resp
/var/lib/selinux. i.e. libselinux would first look into /etc/selinux and
if a file does not exist, look into /usr/etc/selinux. likewise for
libsemanage. It would also use modules from /usr/lib/selinux but
these modules would be overridden by modules from /var/lib/selinux

Policy rebuild (`semodule -R`) would install new policy and modules into
/etc and /var as it's now.