fai and cryptsetup
Brian Kroth
bpkroth at gmail.com
Tue Oct 5 03:57:17 CEST 2010
Michael Tautschnig <mt at debian.org> 2010-10-04 18:44:
> Hi Brian,
>
> > Patrick Schoenfeld <patrick.schoenfeld at googlemail.com> 2010-09-26 13:04:
> > > Hi,
> > >
> > > On Sun, Sep 26, 2010 at 01:00:46AM +0200, Michael Tautschnig wrote:
> > > > Indeed, it was easy :-) - as of 4.0~beta2+experimental17 you should be able to
> > > > use
> > > >
> > > > luks:"Your passphrase" / ...
> > > >
> > > > instead of just "luks" to get a device encrypted with the passphrase of your
> > > > choice. The crypttab then has "none" for the keyfile name, which should make it
> > > > ask you for a passphrase at bootup. Big fat WARNING: this is untested, but
> > > > testing would be much appreciated :-)
> > >
> > > it seems that the implementation is wrong. I can see from the log that
> > > it uses the passphrase to generate a key file. That is not right.
> > > Unfortunately I see the dillemma. You either have to specify a keyfile
> > > to luksFormat or enter the passphrase on generation, which will not work
> > > without using expect or something.
> > >
> > > My suggestion:
> > > - Use the keyfile to init the device
> > > - After that: Add the passphrase via cryptsetup luksAddKey
> > > - Remove the slot with the keyfile from luks
> > > - Generate the crypttab in the way you've described
> > >
> > > I know its kind of ugly but probably the only way to go without
> > > expect'ing the input of luksFormat.
> > >
> > > Regards,
> > > Patrick
> >
> > Late to the party...
> >
> > One other thing I had done a while ago is to randomly generate the
> > passphrase (via pwgen) and email it to the "root user" along with the
> > set of commands necessary for them to change it. Obviously who the
> > "root user" is would have to be set somewhere and the NFSROOT built with
> > that support.
> >
>
> I guess this is best achieved via scripts and/or hooks; I'd prefer not to build
> this feature into setup-storage (but then again I'm not sure you had actually
> been suggesting this).
>
> > I'd also left the key file there rather than removing it. Somewhat as a
> > fallback in case the passphrase was forgotten. I could see this being
> > nice to have as an switch option (eg: lukskeyfile:generate+leave).
> >
>
> Same here: Please go for scripts/hooks instead. Why so? Well, if we leave a
> keyfile around but access is possible using a passphrase the FAI user might
> forget about that extra keyfile; if anybody gets hold of that keyfile, there's a
> security leak, which is pretty hard to spot. Instead, adding a hook or script
> should be pretty easy, it could just pick the passphrase from the disk_config
> file and add a keyfile which is put wherever the user whishes to see it (the
> keyfiles generated by setup-storage are left behind in /tmp/fai). Well, and
> there's the hope that the added pain of adding an extra hook/script makes the
> admin not forget about the extra keyfile.
>
> Best,
> Michael
Agreed, just offering some other options for people to consider when
setting this up.
Cheers,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20101004/700baabc/attachment-0001.bin
More information about the linux-fai
mailing list