monolithic policy on a volatile root

monolithic policy on a volatile root

[Dominick Grift]

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.

-- 
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

Re: monolithic policy on a volatile root

[Stephen Smalley]

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.

Re: monolithic policy on a volatile root

[Stephen Smalley]

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?

Re: monolithic policy on a volatile root

[Dominick Grift]

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?
>

Yes I think the module store could be copied from /usr/share/factory to
/var/lib by systemd-tmpfiles if applicable and it should not cause
issues but the overal idea of using a mutable policy on a volatile root
seems counterintuitive. For a readonly monolithic policy it is probably
robust and simple.

-- 
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

Re: monolithic policy on a volatile root

[Dominick Grift]

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

Re: monolithic policy on a volatile root

[Petr Lautrbach]

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.