On 7/24/20 2:56 PM, Stephen Smalley wrote: > 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. I think i tried that, but the extended attribute filesystems need to be re-initialized AFAIK else fixfiles just returns with "Operation not supported". Not sure if that strictly speaking requires a reboot or if you can somehow do that with mount -o remount? Is there a way to enable labeling support of extended attribute filesystems without rebooting? I think there was a patch recently by the Red Hat ContainerOS people to enable labeling from the initramfs (ie labeling when SELinux is disabled) How does that relate to the issue where I am seemingly not able to relabel the filesystem after adding a fsuse trans rule without rebooting? (ie SELinux is enabled, there is a fsuse xattr but the filesystem hasnt been re-initialized yes and setfiles reports "operation not supported") 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. >
