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

[Marc Haber]

On Thu, Aug 14, 2014 at 08:18:10PM +0200, Lennart Poettering wrote:
> On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-devel at zugschlus.de) wrote:
> > > Not aware of an C++ code. There's a vala one, and of course the one we
> > > ship in systemd itself in C, but c++ i cannot help you with, sorry.
> > 
> > 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 key script hashes part of the key found on the USB key and part of
the key found on the LUKS partition on the hard disk together to build
the actual key to unlock the root fs. I use this scheme for so long
that I don't even remember why I implemented it this way, but I guess
it was because the logic to unlock a LUKS fs from initramfs was
already in place and could be used as-is to unlock the
key-part-holding LUKS partition instead of the actual root fs that it
was intended for.

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.

> > 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.

> As mentioned we really should redesign the whole thing around the kernel
> keyring anyway, I am really conservative in adding support for Debian's
> keyscript thingy upstream now. (That of course shouldn't stop Debian
> from adding this downstream)

It didn't occur to me that /etc/crypttab's keyscript= option was a
Debianism. I educated myself in the mean time. I'm going to yell at
the Debian systemd team now ;-)

> > 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 ;-)

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420