Date: Wed, 03 Sep 2014 15:30:26 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-geom@freebsd.org Subject: Re: Attempt to add multiple device attachment to "geli attach" Message-ID: <54077A62.50606@denninger.net> In-Reply-To: <20140903200014.GB82175@funkthat.com> References: <54076871.5010405@denninger.net> <54076CFE.5010308@denninger.net> <20140903200014.GB82175@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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@denninger.net
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
O0K030
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H
customer-service@cudasystems.net0
130824190344Z
180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H
karl@denninger.net0"0
*H
0
bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R
lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z
lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0
*H
gBwH] j\x`( &gW32"Uf^. ^Iϱ
k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq
aʷ?rk$^9TIa!kh,D -ct1
0001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H
customer-service@cudasystems.net0 + ;0 *H
1 *H
0 *H
1
140903203026Z0# *H
1Mm?p0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H
customer-service@cudasystems.net0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H
customer-service@cudasystems.net0
*H
ۄ|~V#JĴ-%1I# l >U]Xr l$?lQ
C1=2@ɐ`7Vj-*?!NetNpi S@8 x,o<+
D !f*å,=v+0:7\|f~:MWtDRGJ% bE6M-FRw9, #k:(0c+O,T,5.W^T FӀјc0ILnE
4,4e(εWA9l DZ |hȔ5i|UݹfS; u<nA$ &%@v*zAI. H&ϴ RГ8@nU & )[ =_DhHD{ /{&N2>3ΒF5RԲ96 Ck CA!',:{zbj7fkA5cICp+ @PJ0+v!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54077A62.50606>