On Thu, 2014-03-13 at 15:47 +0000, David Howells wrote: > Hi Linus, > > I've encountered a situation where I could do with providign certain key types > with their own operations and I'm wondering as to the best way. > > The problem I've been trying to deal with is to improve quota management on > keys and introduce LRU key discard when a quota is overrun. This requires me > to overhaul all the ->instantiate() and ->update() key type operations as they > can ask for more quota. > > What I want to do is to use the preparsing mechanism I introduced for > asymmetric key handling for both operations. This has the advantage that all > parse errors and invalid arguments can be found upfront before we start > allocating things that are difficult to back out of - and means that we're > less > likely to encounter ENOMEM in the type op functions. > > Now, ->instantiate() is meant to set the payload on a key and ->update() is > meant to replace the payload on a key. There is, currently, no way to modify > a > key to some lesser extent. > > However, in the process of doing this, I've come to realise that the trusted > key type and the encrypted key type use their ->update() operations to make a > partial alteration to a key. > > Unfortunately, this does not lend itself to preparsing because the result > depends on the key we're going to update - and we don't necessarily know the > key yet. > > Further, this behaviour is also broken because ->update() may be called by > add_key() if it finds a matching key; but you cannot rely on add_key() adding > vs updating because it may race with someone else doing an add_key(). To make > matters yet more interesting, at least with encrypted_update(), the parameters > expected in the payload depend on whether you want to create a key or alter a > key. > > I can fix this in one of a number of ways: > > (1) Provide a generic control operation (analogous with ioctl()) that allows > the user to make some general operation on a key (querying it, altering > it, interacting with hardware). > > (2) Provide an alter operation that only allows the key to be altered. > Looking at trusted_update(), though, I have a suspicion that this may not > be sufficient as that also seems to invoke an interaction with the TPM. > > (3) Provide separate, specific keyctl functions for the special operations > required by encrypted and trusted keys (and other key types potentially) > that are then validated in the core and routed to the key type. > > I would prefer (2) or perhaps (3), I think. > > As I understand the code, I think operations being performed from ->update() > are: > > (a) Resealing a key with a new pcrs (trusted). > > (b) Changing the master key (encrypted). > > Mimi, Dmitry: is this list right?
In addition to resealing trusted keys to a new TPM PCR value, there are a few other options that can be modified (eg. keyauth, blobauth, pcrlock). Encrypted keys can be encrypted/decrypted with a new master key (trusted or user key type). Mimi > Note that if I do provide some more appropriate vector, I will probably have > to > have special code for handling encrypted and trusted keyrings in the core, > rejecting attempts to update in key_create_or_update() and redirecting them in > key_update() in security/keys/key.c > > David > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
