Dave Jiang <[email protected]> wrote: > > Can you show me the whole file? > https://lists.01.org/pipermail/linux-nvdimm/2018-July/016958.html
Is that exactly what's in your /etc/request-key.conf? > > As I understand it, you poke an attribute file in sysfs by writing > > "update" to it and this triggers a request_key() call. The kernel then > > links the key it found across to the internal keyring. > > Correct. And when there isn't a key, it needs to fetch from userspace > and construct the key. I think I've missed a step. Am I right in thinking that the "update" command is just for changing the password, and is not the primary way that passwords get into the kernel to, say, unlock the device? > > You could instead require that the key be specified directly, ie. you > > write "update <keyid>" to the attribute file. The driver can then call > > key_lookup() to get the key - or, better still, we should make > > lookup_user_key() available so that you can call that - which will do a > > security check. > > I can attach the keyid to the nvdimm when I initially get a success key > and the update can look it up easily enough. I'm not groking the > lookup_user_key() comment. What determines a key to be a user key or a > kernel key? lookup_user_key() converts a key serial number into a key applies all the security checks to make sure that userspace is allowed to use that key for some purpose. key_lookup(), on the other hand, has no security checks whatsoever. So if you're using a key ID given to you by userspace, you have to use lookup_user_key(). Whereas if you want to find a key by description - and potentially create it - you use request_key(). request_key() also does all the appropriate security checks. So I would be tempted to make the update command take an explicit key ID rather than calling request_key() - particularly as you want to control what the password gets changed to. Possibly even make it take *two* explicit key IDs: the key holding the new password and the key holding the old one. Then you can have security checks on both and you can compare the descriptions to make sure they're the same. David _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
