Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20100123013431.GC35458>