Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Mar 2015 09:55:52 -0600
From:      CyberLeo Kitsana <cyberleo@cyberleo.net>
To:        Mason Loring Bliss <mason@blisses.org>,  freebsd-questions@freebsd.org
Subject:   Re: GELI key question...
Message-ID:  <54F72B08.3020404@cyberleo.net>
In-Reply-To: <20150304015753.GV3375@blisses.org>
References:  <20150304015753.GV3375@blisses.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03/03/2015 07:57 PM, Mason Loring Bliss wrote:
> Hi all.
> 
> Right now I've got root-on-ZFS-on-GELI from the 10.x installer, but I don't
> understand all the moving parts, and I'd love some pointers. In particular,
> the man pages geli(8) and loader.conf(5) don't tell me what I want.
> 
> I've got an ultimate goal and a short term goal. The short term goal is to
> have a key on a USB stick (maybe in a UFS2 partition, maybe just data on the
> disk itself - doesn't matter) and have loader.conf reference that as the key
> to unlock my root disk(s), for unattended boot as long as the USB stick is
> inserted in the system.
> 
> First thing that's unclear: Where is the GELI syntax for loader.conf
> documented? The GELI man page gives examples of use, but it doesn't say how
> the configs are composed.
> 
> For example, it shows this:
> 
>            geli_da0_keyfile0_load="YES"
>            geli_da0_keyfile0_type="da0:geli_keyfile0"
>            geli_da0_keyfile0_name="/boot/keys/da0.key0"
> 
> Is the name of the variable fixed there? What's interpreting it? Would this
> be valid?
> 
>            geli_foo_keyfile0_load="YES"
>            geli_foo_keyfile0_type="da0:geli_keyfile0"
>            geli_foo_keyfile0_name="/boot/keys/da0.key0"

The names of the variables themselves mean nothing, excepting that they
must all match and follow this pattern. The way the loader processes
these is as such:

foo_load="YES" <- We want to load a module we call 'foo'.
foo_type="da0:geli_keyfile0" <- Set the 'foo' module type.
foo_name="/boot/keys/da0.key0" <- Set the path to the 'foo' module data.

The 'type' is merely a tag so that the code in the kernel can find it
later, after control is passed thereto.

For geli keyfiles, the type consists of the device name, a colon, the
phrase 'geli_keyfile', and the position of the keyfile (since you can
load multiple, and they are all concatenated in order).

> More relevant, can the _name variable specify another device? If so, can I
> use gpt labels for this, so that I can point to gpt/keypart? Or are those
> only available once the system has booted? I'd like to not have to depend on
> the USB key having the same device on each boot, and gpt labels seem ideal
> for this.

I doubt this, as the loader is really only guaranteed to know about the
boot filesystem. If you were to try, you would have to figure out how to
refer to the devices by their loader names (disk0, disk1), and not by
their kernel names (da0, ada0). It is not outside the realm of
possibility to teach loader(8) to understand labels, but nobody has done so.

> Next, I don't see loader.conf specifying which slot to use. I could be
> confusing the concepts... My understanding is that there is one key and a
> couple slots for user keys. Is my idea of having the bootloader default to
> the USB stick unless it's not there and use a file-and-passphrase already on
> /boot otherwise feasible? I'm not sure how to specify an order to try, never
> mind the location on another device of one of the keys.

The geli attach code will try all slots until it finds one that works;
if none match, it will request a passphrase to combine with the keyfiles.

> <cough>
>     end_of_line? if 0 else letter? digit? underscore? dot? or or or then
> </cough>

Mmm, reverse-polish notation.


-- 
Fuzzy love,
-CyberLeo
Technical Administrator
CyberLeo.Net Webhosting
http://www.CyberLeo.Net
<CyberLeo@CyberLeo.Net>

Furry Peace! - http://www.fur.com/peace/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F72B08.3020404>