On 9/3/2014 15:00, John-Mark Gurney wrote:
Karl Denninger wrote this message on Wed, Sep 03, 2014 at 14:33 -0500:Never mind... I know what I missed -- the key generation that is passed in is dependent on the metadata read from the userspace.More work to do here.... will have to pass a separate key structure for each disk and it will also require some more work in the userspace command area so it doesn't prompt a second time for a password. I'll post the completed patch set once I have it if people here think it would be interesting.Just some comments on this as I've thought about this issue... There are two issues here, one is for root and one is for geli volume mounted later... For the later, I personally use a key volume that is encrypted, and uses that "key store" for my large 8 disk raidz pool.. This is less of an issue, but still requires me to type in the password twice... It basicly boils down to: (cd /zkeys && for i in *.key; do geli attach -p -k "$i" "label/${i%.key}"; geli attach -p -k "$i" "gpt/${i%.key}"; done) || exit 5 I have to do both label and gpt since disks are labeled, but things like zlog are on gpt partitions... I haven't reviewed your patch, nor have I looked at how geli keys volumes upon init, but make sure that you have each volume's master key salted seperately... This way if the volumes get seperated from your system, it won't leak that they use the same key... Yes, it'll take a bit more cpu time to unlock, but not that big of an issue IMO...
Yeah, that's basically the issue.The userspace code (the geli link to /sbin/geom) does that; it grabs the metadata and uses it as part of the salting, so the key passed to the kernel is unique even if the passphrase is identical. That's why the second pack attach fails the way I tried to do this.
This in turn means that the pass to the kernel driver has to have a unique key for each argument (pack) you pass for attachment. Right now the code passes the parameter "key" in the request structure; this will have to be changed to be "key0", "key1", etc.
That in turn means that if you pass more than one argument to "geli attach" the userland code has to ask for the password for the first argument but not ask for each subsequent one. That means the userland code has to save the password typed so if the "get the password" routine is called again during the same invocation (as the code iterates over the listed devices) instead of prompting it just picks up the saved value, iterates over each volume and stuffs the appropriate key structure into the parameter list. I have to put some thought into that though to minimize the risk of that keyed password leaking......
I'm going to noodle on this a bit.... I think I can get where I want to go without adding more risk than the obvious (e.g. if someone gets the password they now have the key to unlock all the volumes involved, but if you're not using unique passwords for each that's already a risk you're accepting.)
-- -- Karl [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
