[dm-crypt] Shared library for cryptsetup

[dm-crypt] Shared library for cryptsetup

[Jürgen Pabel]

Hi all,

I would like to see the shared library included in the next release (ie:
establishing a somewhat stable API+ABI). I know this has been focused on
in the past and some work has already been done - but: I would really
like to see this to be an official part of a release in the near future.

Why? My project "tokentube" is an integration component between LUKS and
credential verification via PAM on Linux. It allows for users to use
their Linux username and password to unlock LUKS during system startup
(instead of a dedicated encryption passphrase). There's a presenation
online in case you want to know more about tokentube:

http://programm.froscon.org/2009/attachments/93_From%20PBA%20To%
20Login.pdf

It would be great if I could employ a custom binary to do the
initialization (which includes adding a new key to LUKS) instead of
calling the cryptsetup binary from configuration scripts.

Regards,
Jürgen

-- 
Jürgen Pabel, CISSP

Akkaya Consulting GmbH
Eupener Straße 137
50933 Köln

Telefon: +49 221 9473007
Telefax: +49 221 4911970
Mobil:   +49 160 8806133

E-Mail:   jpabel@akkaya.de
Internet: http://www.akkaya.de

Re: [dm-crypt] Shared library for cryptsetup

[Milan Broz]

Jürgen Pabel wrote:
> I would like to see the shared library included in the next release (ie:
> establishing a somewhat stable API+ABI). I know this has been focused on
> in the past and some work has already been done - but: I would really
> like to see this to be an official part of a release in the near future.

yes, it will be released soon in version 1.1. I also changed soname and start
to version symbols to not repeat the broken API/ABI problems.
(Old functions are still exported, so only rebuild is needed here for old applications.)

See the cryptsetup devel source code (new API functions are documented
directly in libcryptsetup.h), there will be probably some new functions before
release added (header backup related), but current calls should be stable.
(But if you find some mistake in design, please let me know.)

Milan

Re: [dm-crypt] Shared library for cryptsetup

[Ludwig Nussel]

Jürgen Pabel wrote:
> Why? My project "tokentube" is an integration component between LUKS and
> credential verification via PAM on Linux. It allows for users to use
> their Linux username and password to unlock LUKS during system startup
> (instead of a dedicated encryption passphrase). There's a presenation
> online in case you want to know more about tokentube:
> 
> http://programm.froscon.org/2009/attachments/93_From%20PBA%20To%20Login.pdf

Interesting idea. I wonder whether those separate key files per user
are worth the effort though. LUKS has eight key slots so when
reserving one for the admin you still have seven left for users.
Have you considered simply storing a mapping of user names to key
slots?

Also, as long as you're using local authentication you don't need to
store the password for pam authentication. Should be sufficient to
just reconfigure the displaymanager to auto login the user that
unlocked the root device.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [dm-crypt] Shared library for cryptsetup

[Jürgen Pabel]

Hi,

> Interesting idea. I wonder whether those separate key files per user
> are worth the effort though. LUKS has eight key slots so when
> reserving one for the admin you still have seven left for users.
> Have you considered simply storing a mapping of user names to key
> slots?

Well, one of the major reasons was that it eliminates this limit
(although I agree that it's usually not really limit with practical
implications).

Another reason is that tokentube allows for different deployment options: it's
possible to configure the system in such a way that the user's auth files (key
files) are in fact owned by the user. That's not a common scenario but I've
seen environments which required such setups.
 
> Also, as long as you're using local authentication you don't need to
> store the password for pam authentication. Should be sufficient to
> just reconfigure the displaymanager to auto login the user that
> unlocked the root device.

True, but that requires "raw" device access (instead of "working" at the
filesystem layer) - which most often requires root (or at least appropriate
group) privileges for accessing the "raw" device during execution (like via
setuid'ing the binary). 

All in all, I think it's a "clean" solution for the stated problem.

jp

Re: [dm-crypt] Shared library for cryptsetup

[Ludwig Nussel]

Jürgen Pabel wrote:
> > Interesting idea. I wonder whether those separate key files per user
> > are worth the effort though. LUKS has eight key slots so when
> > reserving one for the admin you still have seven left for users.
> > Have you considered simply storing a mapping of user names to key
> > slots?
> 
> Well, one of the major reasons was that it eliminates this limit
> (although I agree that it's usually not really limit with practical
> implications).
> 
> Another reason is that tokentube allows for different deployment options: it's
> possible to configure the system in such a way that the user's auth files (key
> files) are in fact owned by the user. That's not a common scenario but I've
> seen environments which required such setups.

Wouldn't that expose the master key to the users?

> > Also, as long as you're using local authentication you don't need to
> > store the password for pam authentication. Should be sufficient to
> > just reconfigure the displaymanager to auto login the user that
> > unlocked the root device.
> 
> True, but that requires "raw" device access (instead of "working" at the
> filesystem layer) - which most often requires root (or at least appropriate
> group) privileges for accessing the "raw" device during execution (like via
> setuid'ing the binary). 

The password is changed via pam module which typically runs as root
anyways (/usr/bin/passwd is usually setuid root). Also I expect e.g.
DeviceKit to add a luks key change method sooner or later which
wouldn't require direct device access by the user either.

> All in all, I think it's a "clean" solution for the stated problem.

Well, if the slot limit is no problem the tokentube way looks rather
complex to me :-)

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [dm-crypt] Shared library for cryptsetup

[Heinz Diehl]

At Mon, 12 Oct 2009 11:12:29 +0200,
Ludwig Nussel wrote:

> > Another reason is that tokentube allows for different deployment options: it's
> > possible to configure the system in such a way that the user's auth files (key
> > files) are in fact owned by the user. That's not a common scenario but I've
> > seen environments which required such setups.
 
> Wouldn't that expose the master key to the users?

This is exactly what I thought, too.
 
> > > Also, as long as you're using local authentication you don't need to
> > > store the password for pam authentication. Should be sufficient to
> > > just reconfigure the displaymanager to auto login the user that
> > > unlocked the root device.

Adding a big amount of complex code to an already working solution raises the chance of
putting a security hole into it. And there is also to consider that by far not
all users are using PAM at all. 
  
Generally, I think the level of adding complex and new code to cryptographic
software should be a hundred times higher than usual, because every line of
code raises the possibility of introducing a flaw, which often renders the whole
software unuseable.