Here are some keyring mysteries. If my uid is *not* 1001, and uid 1001 is not currently logged in but uid 1001 will log in soon, this does terrible things:
$ keyctl newring _uid.1001 @us In general, I do not understand how it is possible to use find_keyring_by_name safely. (This may need a CVE number assigned if it's as bad as I think it may be. I see no a priori reason that it can't be used to trivially steal Kerberos credentials.) What does it mean to revoke an entire keyring? keyctl revoke @u seems to do something odd. Are you supposed to be able to recover from keyctl setperm @u 0? What is a possessed key? If I have KEY_LINK, does that mean I can possess a key and possibly elevate my permissions? What's up with key_fsuid_changed? It looks like it's a giant security hole in any case where it has any effect at all and setfsuid is being used. But maybe I don't understand the point. Why doesn't key_change_session_keyring use prepare_creds? Why do keyrings live in struct cred? Especially, why is thread_keyring in there? I'd really like to get rid of that. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
