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)
