On 7/24/20 2:23 PM, Stephen Smalley wrote: > On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift > <dominick.grift@xxxxxxxxxxx> wrote: >> >> >> >> On 7/23/20 3:24 PM, Stephen Smalley wrote: >> > There is a tension there with fail-closed versus fail-open and the >>> potential for a security vulnerability to arise if it proceeds. Would >>> have to look at the specifics to evaluate how it should be handled. >>> Of course, in practice, one really shouldn't be removing contexts >>> while they are still in use (or else use aliases to preserve some >>> degree of compatibility). >>> >> >> I guess if there is tension be between GNU/Linux use of libselinux and >> SEAndroids use of libselinux, where SE for Android is implemented by the >> vendor to be immutable by the device owner, and where GNU/Linux >> leverages SELinux to empower device owners, then any tension can be >> alleviated if Google forks libselinux. In GNU/Linux it should just be >> possible to switch policies. > > I wasn't talking about Android, just about the tension of > fail-closed/secure versus fail-open/insecure in general. > I don't have any problem with someone installing a new policy that > completely changes the set of file contexts; I just don't think they > should do that at runtime without a reboot in between and expect > things to work seamlessly. > Yes but that is not what I am saying. It does not work even when you reboot. I tried to explain that: You install a new policy and run fixfiles -F onboot && reboot (as one should) systemd will fail to compute create socket activated sockets. and so these socket activated daemon fail to start. One of the daemons is device-mapper, and so if you use LVM type stuff you may end up with with a system that is only partially relabeled. Not to mention that in the relabel target various other services that are socket activated fail to start, and so who know how else that may affect things. There is also this (however this might no longer be accurate): systemd computes whether it can dynamically transition on boot. If the systemd executable file has an invalid label and this computation fails then systemd might just freeze in the first place.
