Re: monolithic policy on a volatile root

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

 



On Fri, Aug 2, 2024 at 7:45 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> On Fri, Aug 2, 2024 at 4:27 AM Dominick Grift
> <dominick.grift@xxxxxxxxxxx> 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?





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux