On Mon, Apr 27, 2020 at 10:36 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Mon, Apr 27, 2020 at 10:13 AM David Howells <dhowells@xxxxxxxxxx> wrote: > > > > Paul Moore <paul@xxxxxxxxxxxxxx> 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 > permissions? > > > > > 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 > > s/security_sid_to_context/avc_has_perm > > > 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 SELinux. -- paul moore www.paul-moore.com
