On Tue, Feb 14, 2017 at 10:27:28PM -0800, Eric Biggers wrote: > I think you may be confusing keys and keyrings. "logon" is a type of key, not a > type of keyring. The semantics of a "logon" key are that it can be created and > updated by userspace, but cannot be read by userspace. (See > Documentation/security/keys.txt.) Despite the name it does not need to be tied > to an actual user "logging in" per se, and you can add a "logon" key to any > keyring, either one of the special ones like a session keyring, or to a manually > created one. > > Also, session keyrings do not need to be tied to other concepts of a "session"; > a process can simply set one up, and it gets inherited by children. So it would > be possible for init to insert the key into its session keyring, and then all > processes would inherit it, unless they explicitly replace it. > > If I'm not mistaken, Android actually uses a global keyring quite similarly to > that. I think the only real difference is that a privileged process on Android > adds and removes keys as users log in and out, whereas you'll need to add a key > at init time only. > Nope, Android uses a session keyring, and takes special care to make sure all user processes belong to that session. There is, unfortunately, no such thing as a global keyring. Subsystems like which need global access to keying material, such as dm-crypt, don't use the keyring abstraction. - Ted
