The separation is necessary for a few reasons:
(1) The task victimisation context must *not* be changed by a temporary
override of the action and creation contexts for purposes such as
cachefiles.
(2) If the victimisation context is not included in the override cred, then I
only need one copy of the override cred to do *all* the work for
cachefiles. I can share that singular override blob across every task
that wishes to access the cache.
(3) If the victimisation context is moved to the override cred, I have to
create a new context every time I want to apply the override. This means
I have to deal with the possibility of OOM at such points. I could cache
the contexts, but that's messy - and unnecessary.
Indeed, but I can help it to do so by providing separate security pointers on
the task struct and the cred struct.
The separation is, I think, the correct thing to do.
Whilst that is true, one of the purposes of this is to make it easier and
cleaner to effect the override. Every field in the cred struct potentially
must be overridden. That's a lot of context to save each time I need to apply
the override and a lot of context to restore each time I want to restore it.
With these patches, all I need to do is to take a ref and swap the cred
pointers with a memory barrier to satisfy the RCU, and then swap them back
again and release the ref. It's much, much simpler.
Furthermore, with respect to LSM and SELinux, I think I can remove the SELinux
specific knowledge currently present in cachefiles by saying to LSM "give me a
cred for kernel service X". With SELinux this can do all the transformations
necessary to give me the appropriate action SID and file creation SID without
me needing to know that these concepts exist. I just apply the cred I'm given
as an override.
With your suggestion, I either have to do a full set of transformations each
time I want to apply the override, or I have to know about SELinux or
whatever's internals. Your objection to my earlier patch was this very point.
David
-
