[PATCH] selinux: Fix use of KEY_NEED_* instead of KEY__* perms
paul at paul-moore.com
Mon Apr 27 15:24:17 UTC 2020
On Mon, Apr 27, 2020 at 10:36 AM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
> On Mon, Apr 27, 2020 at 10:13 AM David Howells <dhowells at redhat.com> wrote:
> > Paul Moore <paul at paul-moore.com> wrote:
> > > Okay, can you send the next version of the patch to the SELinux list for
> > > review?
> > Here you go. Note that I did this a few days ago and I actually used EACCES
> > rather than EPERM. Which one is one preferred for this?
> Generally SELinux returns EACCES unless the hook normally returns
> EPERM (e.g. capable).
> Should we use a build-time or runtime guard to catch introduction of
> new KEY_NEED values without corresponding SELinux
> > David
> > ---
> > selinux: Fix use of KEY_NEED_* instead of KEY__* perms
> > selinux_key_getsecurity() is passing the KEY_NEED_* permissions to
> > security_sid_to_context() instead of the KEY__* values. It happens to work
> > because the values are all coincident.
> Shrug. That was just a requirement on key permissions when they were
> introduced; same is true of capabilities.
> Not opposed to explicitly mapping them now but it isn't really a bug.
I haven't looked at the rest of the patch yet, but I wanted to make a
quick comment on this ... over the years I've seen a number of
problems that crop up because of cross-subsytem assumptions, unless
there is some performance critical path where the mapping is
problematic I would prefer to see a translation layer to help protect
More information about the Linux-security-module-archive