[systemd-devel] Thoughts about /etc/crypttab keyscript options

[Lennart Poettering]

On Fri, 15.08.14 12:56, Marc Haber (mh+systemd-devel at zugschlus.de) wrote:

> > > Is it possible to write a PasswordAgent in shell? Example code please
> > > ;)
> > 
> > Probably possible, after all bash allows you to talk to unix sockets and
> > stuff. And you could probably put the protocol together with carefully
> > crafted echo lines, but I know of nobody who has done that so far...
> 
> There is also the daemonizing and inotify part...
> 
> > > > I fear I don#t have an easy suggestion. What kind of device do you
> > > > actually want to make work here? some smartcard or so?
> > > 
> > > That's the vision, yes. At the moment, my keyscript unlocks a small
> > > LUKS partition on the disk and takes the key for the root fs from
> > > there. That's just a placeholder for a future more complicated setup.
> > 
> > Not following. You place a key for a LUKS partition on another LUKS
> > partition? What's the benefit of that? Inception? ;-)
> 
> It's actually part of a two-factor-authentification for the poor. The
> part to know is the key to the LUKS parition, the part to have is an
> USB key.

The part to have is trivially easy to copy, so why do the excercise
at all? Sounds more like theatre to me...

> But I also know of people who use a keyscript to unlock LUKS file
> systems with the key stored in the system's TPM or on a crypto card. I
> have never looked into the details of those implementations (having
> that saved for a long winter night), but I guess that those people
> will also be pretty hosed on a systemd-based Debian.

I think supporting TPM or smartcards out of the box is very desirable to
have upstream. I am not convinced though that Debian's keyscript= logic
is really that well designed that I want to update it upstream. (But
again, Debian can ship such a patch downstream)

> > > First step to do that would be to implement support for the keyscript=
> > > option in /etc/crypttab as this is the canonical place to hook into on
> > > non-system systems. At least it's the case on Debian, I don't know
> > > about Red Hat, Fedora and other distributions.
> > 
> > Well, I am really not convinced that this is a well-defined
> > interface. Even in your case you have to wait for two devices at least,
> > right? a synchronous shell callout won't solve that for you since
> > there's no guarantee that the second LUKS device has already shown up,
> > or am I missing something?
> 
> It may be possible that /etc/crypttab is processed sequentially which
> would obviously not be the case with systemd. So you have a point
> here.

Modern design probing really doesn't work that way anymore. You never
know when all devices have shown up. If you want to implement something
like your USB key thing, then you'd have to explicitly wait for both
devices.

On old Debian and the other sysv distros, boot scripts generally
included an "udev settle" call, which was supposed to wait until "all"
devices have shown up. But that's not actually something that could work
at all on many of the newer tehcnologies where the probing time is
basically unbounded. One of those busses is actually USB, where there's
no restriction made at all, when devices have to have told the OS about
the storage devices they want to provide (and this fact is used by
android phones, where you need to press OK on the phone before a USB
device pops up in the system, after you connected the cable).

So, nowadays no sane distribution uses "udev settle" anymoer, since it
cannot deliver what people assume it delivers, and in particular not on
USB, which you are looking for.

Anyway, long story short: what you are doing worked mostly out of luck,
not out of correctness..

> > > The PasswordAgent stuff is really neat, but complicated due to the
> > > socket communication, and it's far from being a drop-in replacement.
> > 
> > Well, it's really easy in C I figure, but admittedly not in shell...
> 
> It would be significantly easier if there were boilerplate code to
> derive from. To a non-adept programmer, adapting the boilerplate would
> probably lead to enough buffer overflow vulnerabilities anyway ;-)

Well, we have examples in our code, but really only in C, and they are
not minimalist examples, but real code...

Lennart

-- 
Lennart Poettering, Red Hat