On 7/23/20 3:24 PM, Stephen Smalley wrote: > On Thu, Jul 23, 2020 at 9:04 AM Dominick Grift > <dominick.grift@xxxxxxxxxxx> wrote: >> >>+++ >> >> On 7/23/20 2:22 PM, Stephen Smalley wrote: >>> On Thu, Jul 23, 2020 at 4:13 AM Dominick Grift >>> <dominick.grift@xxxxxxxxxxx> wrote: >>>> >>>> >>>> >>>> On 7/22/20 7:32 PM, Stephen Smalley wrote: >>>>> On Wed, Jul 22, 2020 at 12:57 PM Dominick Grift >>>>> <dominick.grift@xxxxxxxxxxx> wrote: >>>>>> Can we not just assume that if that happens, that the kernel should just >>>>>> treat the context as if it were the context of the unlabeled isid. >>>>> >>>>> No, because then a simple typo or other error in a context provided by >>>>> a user or application would end up being handled as the unlabeled >>>>> context instead of producing an error return that can be handled by >>>>> the application or user. >>>> >>>> So are you saying that it is up to the libselinux consumers to deal with >>>> this? what do you suggest they do in these situations? >>> >>> libselinux cannot handle it in the general case. If using the >>> userspace AVC and SIDs obtained via avc_context_to_sid(), then >>> libselinux could transparently re-map those to the unlabeled context >>> if they cease to be valid. Otherwise, it is up to the callers to deal >>> with and the correct handling is application-specific. SEPostgreSQL >>> does this for example: >>> https://github.com/postgres/postgres/blob/master/contrib/sepgsql/label.c#L460 >>> >>> However, I don't think that would help something like systemd; even if >>> you re-map the context to the unlabeled context, you aren't going to >>> get a useful result from security_compute_create() or similar to use >>> in labeling sockets, processes, files, etc.> >> >> I suppose systemd probably should not fail "hard" when getfilecon (or >> whatever) fails and returns with "invalid argument", and it should then >> just not use setfilecon rather than not create the object at all (as it >> seems to be doing now) > > 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.
