Re: monolithic policy on a volatile root

[Dominick Grift <dominick.grift@defensec.nl>]

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

> On Fri, Aug 2, 2024 at 7:45 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>>
>> 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.
>
> To clarify, for monolithic policy, you just need to update libselinux
> to fall back to searching /usr if /etc lacks the file.
> For modular/managed policy we would also need to update libsemanage to
> write the final policy files somewhere, although /var seems more
> appropriate than /usr for that?

I misread. I also think the I might be overlooking use-case but the main
point I would like to make is that with a volatile root / is empty
except that there is a readonly /usr mounted. With that said I don't see
how using /var would be an solution.

systemd-tmpfiles and systemd-sysusers run very early to populate the
filesystem from /usr/share/factory and to create users. Both of them
rely on a working libselinux. Hence the chicken and egg.

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl