Re: [SELinux-notebook PATCH v8] objects.md: some clarifications

From: Dominick Grift <dominick.grift@defensec.nl>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [SELinux-notebook PATCH v8] objects.md: some clarifications
Date: Fri, 24 Jul 2020 15:06:10 +0200	[thread overview]
Message-ID: <fde88aa9-1f4d-fb60-b27e-0da093753cdf@defensec.nl> (raw)
In-Reply-To: <CAEjxPJ5P7qGybMfhXaEVoUWWiRubhT=1NCNL-oKaY9CXjjqodg@mail.gmail.com>

On 7/24/20 2:56 PM, Stephen Smalley wrote:
> On Fri, Jul 24, 2020 at 8:29 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>>
>>
>> On 7/24/20 2:23 PM, Stephen Smalley wrote:
>>> On Fri, Jul 24, 2020 at 3:54 AM Dominick Grift
>>> <dominick.grift@defensec.nl> 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.
> 