On Fri, Feb 28, 2020 at 10:56 AM David Howells <dhowells@xxxxxxxxxx> wrote: > > Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > Regardless, we need to revert the original patch and create a new one that > > addresses the KEY_NEED_PARENT_JOIN issue I mentioned and that adds the > > key_perms capability in the right place in the first place, not apply a fix on > > top. > > I think the problem is that selinux_key_permission() is munging the new perm > set into the old perm set and then passing that to avc_has_perm(). Really, we > need to work backwards if the SELinux policy is described in terms of the old > perm set. > > Is there any way to make that possible? That's not the problem. The problem is that security_key_permission() needs to be passed something (an additional flag or a different permission) in order to differentiate the two different callers so that SELinux can support both the old logic (when the new key_perms capability is disabled) and the new logic (when it is enabled). The old patch tried to do this by introducing a new KEY_NEED_PARENT_JOIN permission. But it didn't expose this as a KEY_ACE value and therefore creates a conflict/inconsistency between the ACE permissions and the internal permissions. Either it needs to be exposed as a legitimate ACE value too, or it needs to be handled differently, e.g. as an additional kernel-internal flag that gets passed down so SELinux can distinguish them.
