Keyring mysteries

[Andy Lutomirski]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/