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). > Using aliases is not a practical solution IMHO (although I suppose it could be useful temporary hack), and effectively "removing contexts while they are still in use" will alway's be the case in the current state (even autorelabel will effectively generally run when the filesystem has invalid labels, because that is the whole purpose of the app) Maybe we should should rethink that whole autorelabel concept. Do we really have to re-initialize filesystems in order to enable labeling support? Should I be able to load a different policy at runtime, then add a fsuse xattr rule, and be able to relabel at runtime without a reboot, or without somehow re-initializing the filesystem?
