Date: Sat, 23 Jan 2010 02:34:31 +0100 From: Roland Smith <rsmith@xs4all.nl> To: Scott Bennett <bennett@cs.niu.edu> Cc: freebsd-questions@freebsd.org Subject: Re: GELI file systems unusable after "glabel label" operations Message-ID: <20100123013431.GC35458@slackbox.xs4all.nl> In-Reply-To: <201001220908.o0M980UG017425@mp.cs.niu.edu> References: <201001220908.o0M980UG017425@mp.cs.niu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 2010 at 03:08:00AM -0600, Scott Bennett wrote: > > Why is that stored in the last sector of the device, rather than in = the > key file? What is the purpose of the key file if not to hold that type of > information? All geom(4) providers use their last sector to store metadata; it's a design decision. Probably because the first sector(s) are used for boot blocks or filesystem metadata etc. It would have been possible to store the generated key in the user-provided keyfile. But since it is not mandatory to have a keyfile (you can also use just a passphrase), it makes more sense to use the already provided metadata space in the last sector. > >Well, it should be different, otherwise they overwrite the same sector. = Ipso > >facto you should nest providers... >=20 > ...unless, of course, the two had been designed to use different par= ts > of the "last sector" for their own purposes, but also to avoid damaging t= he > other's data when altering their own. The geom framework was designed to be _extensible_. It was designed so that= it would be possible to combine (nest) different types of geom providers, even= if those classes (types of providers) didn't even exist when the framework was designed. Trying to shoehorn all metadata for any combination of geom providers into on 512-byte sector would have severely limited the usability= of the geom system. In my opinion the solition of using nested providers each using their own l= ast sector for metadata is simple and elegant and avoids that problem rather ni= cely.=20 As I've been trying to explain, the 'nesting' of geoms is _precisely_ what avoids the whole issue of damaging each others data. I've got the feeling that you do not 'get' that concept, which lead to your= problem. Unfortunately, I don't know how to explain it more clearly.=20 > Thanks for the explanation. However, if the key information is stor= ed > in the "last sector" rather than in the key file, then I guess I'm totally > confused about how GELI works. The encryption key is _not_ stored in the last sector. That would be unsafe, like locking your front door and leaving the key in the lock. But a part of= the information necessary to create the encryption key is. Your keyfile is just one component of the en- / decryption key to unlock the data. They are not the same. You can use one or more keyfile(s), a passphra= se or both. You can also have more than one key; a user key and a 'company' or system key. And geli uses a random component when the encryption key is initially created. The metadata sector is the natural place to store some of that info. This is safe because it is in itself not sufficient to create the en- / decryption key. One also need the keyfile and/or passphase. Personally, I would never use only a keyfile; it is not really secure, especially if you leave that key on another unencrypted partition of the sa= me drive! So-called two-factor authentication (something you have [keyfile] and something you know [passphrase]) is much safer. If you really want to know how geli works, as always with free software, the source code is the ultimate reference. :-) Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktaUicACgkQEnfvsMMhpyXfNACgiuthg9JlCIU07S34N4RiL/mq 1SgAn0cjMpvQjl6WshqipTMg3AlLP7NJ =KLtS -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100123013431.GC35458>