On Tue, Feb 21, 2017 at 05:16:57PM -0800, Eric Biggers wrote: > Hi David (or anyone else experienced with Linux keyrings), > > I was surprised to discover that the keyctl_invalidate() operation, as added by > commit fd75815f727f1 ("KEYS: Add invalidation support") only requires Search > permission. > > AFAICS, this means that any process which has permission to find a key in > searches can also "invalidate" it, which deletes it from all keyrings > system-wide. This cannot even be forbidden by SELinux, which likewise is only > asked for "Search" permission on the key. > > This is very problematic on systems that want to have a privileged process like > 'init' set up a keyring, then give less privileged processes read-only access. > > What is the motivation behind only requiring Search permission, and how should > this be fixed? Perhaps "invalidation" should require write access to all the > keyrings the key is in, since it's similar to unlinking it from all of them? Or > am I missing something about why it was designed the way it is? > > Thanks! > > Eric > David, do you have any comments on this? This seems to be a pretty serious flaw because it makes it impossible to give processes read-only access to keys. What would you say about solving this by making keyctl_invalidate() require both Setattr and Search permission? - Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |