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
This is a cryptographically signed message in MIME format.
--------------ms030204030709010703090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
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 passe=
d
>> in is dependent on the metadata read from the userspace.
>>
>> More work to do here.... will have to pass a separate key structure fo=
r
>> 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 use=
s
> 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 lik=
e
> 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=20
kernel is unique even if the passphrase is identical. That's why the=20
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=20
unique key for each argument (pack) you pass for attachment. Right now=20
the code passes the parameter "key" in the request structure; this will=20
have to be changed to be "key0", "key1", etc.
That in turn means that if you pass more than one argument to "geli=20
attach" the userland code has to ask for the password for the first=20
argument but not ask for each subsequent one. That means the userland=20
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=20
the listed devices) instead of prompting it just picks up the saved=20
value, iterates over each volume and stuffs the appropriate key=20
structure into the parameter list. I have to put some thought into=20
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=20
go without adding more risk than the obvious (e.g. if someone gets the=20
password they now have the key to unlock all the volumes involved, but=20
if you're not using unique passwords for each that's already a risk=20
you're accepting.)
--=20
-- Karl
karl@denninger.net
--------------ms030204030709010703090103
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC
BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI
EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv
bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5
MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg
RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th
d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W
6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV
jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5
SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY
5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8
Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4
GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci
WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN
nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB
o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg
hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4
+LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG
CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy
bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO
31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c
L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1
YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD
pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE
f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk
YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD
VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2
aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDMyMDMwMjZaMCMGCSqGSIb3DQEJBDEW
BBSb8PBNbY/nrj/e2OPO4vx/nPCQcDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT
EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq
hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG
9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV
BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk
YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh
c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAhI/bhHzeFKp+ViNKxLQZLSW3MZRJ
/SMA5otsjMkPAPI+FaVVjF1YcgIcbCQ/bI9RDUMxPcUGsMwU8huvBqr15DKAmEDJkIX032A3
VrBqxs4t1n/hFhLPzX8qkz+m9yFOZXROcGne0xzNA1MRQIzEOOi1AJWKeN0s2m/i5jwrDUQg
IZX4oNxm3irDpeYsPXbMKzA6sQOeN55cfM5mfsI6TVd0m0SbUscElEdKJSDqYkXFNurNTS2h
RpwaUnc57tEsoeodlCNrOijRMBdjuuEr3eZP2izGVCw1LlexXpFUAMQYxUbTgNGYFN37Y5qn
MEnoTODabkW3DTQEA+osFbn5NLhl+/AIA5QozrVXQfPmOWwg6MXHsbPC5ACxfBNor7+88siU
NWl8VeDduftmp+nbU6vIO8UgmOl1EYw82W5BtyQAtSYl9ECfsnYqev2vAYVBSfAS/oedqC6s
vBggtkgmzM+0AL8UUtCTgIo46xn6QL8IsKLkbo/3BJEZuoQIkwfr/1WyoCATJrTC0Qm5yynE
W4wJPV9EkJdoSMwIiJgWRHsfL67We9UmTjI+gjPozpJGq5m7NVLUsr85NvAJwcpDax3fQ9cE
9u5BziEnLPeiOv/je+sS5uV6YvD7ajdmt76Sa0GGNeakw2Ofy/JJQ3Ar0ABAUEq3MCvhdve9
Id8JC5EAAAAAAAA=
--------------ms030204030709010703090103--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54077A62.50606>