Attempt to add multiple device attachment to "geli attach"

[Karl Denninger]

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
karl at denninger.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20140903/f7cfef4e/attachment.bin>