On Fri, Jul 24, 2020 at 8:29 AM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > > > 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. I think for this kind of complete policy changeover, you need to relabel prior to rebooting. Obviously that carries its own set of challenges; you'd at least have to switch to permissive mode first and potentially run setfiles in a domain (e.g. setfiles_mac_t) that is allowed to get/set contexts unknown to the current policy (CAP_MAC_ADMIN + capability2 mac_admin permission) or load the new policy prior to running setfiles. Or boot with SELinux disabled, label via setfiles, and then boot with the new policy. The preferred model of course is to install with the desired policy in the first place. IIUC Android upgrades are a bit different in that they reboot into recovery mode, create the new filesystem (required anyway for dm-verity) with the correct labels for its policy, and then reboot into normal mode. I don't think the separate autorelabel service can work for whole policy changeovers; it would need to be done directly by systemd itself prior to any other actions. I think Android's init does something like that for the userdata partition since that doesn't get replaced on upgrades.
