Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes: > 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? > 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@xxxxxxxxxxx (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@xxxxxxxxxxx
