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.
