From owner-freebsd-geom@FreeBSD.ORG Wed Sep 3 20:30:36 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51FC9A98 for ; Wed, 3 Sep 2014 20:30:36 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A8DE1004 for ; Wed, 3 Sep 2014 20:30:35 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s83KUVkC074013 for ; Wed, 3 Sep 2014 15:30:31 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Sep 3 15:30:31 2014 Message-ID: <54077A62.50606@denninger.net> Date: Wed, 03 Sep 2014 15:30:26 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Re: Attempt to add multiple device attachment to "geli attach" References: <54076871.5010405@denninger.net> <54076CFE.5010308@denninger.net> <20140903200014.GB82175@funkthat.com> In-Reply-To: <20140903200014.GB82175@funkthat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030204030709010703090103" X-Antivirus: avast! (VPS 140903-0, 09/03/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:30:36 -0000 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--