[dm-crypt] LUKS credential management at an enterprise level

[dm-crypt] LUKS credential management at an enterprise level

[Jeff Diehl]

Is anyone aware of a product/tool that can manage LUKS credentials at an 
enterprise level.  More specifically, something that can deal with 
things like password rotation.

--
JD

Re: [dm-crypt] LUKS credential management at an enterprise level

[Arno Wagner]

In principle, any tool that can reasonably interface to
a commandline interface can do this, see the FAQ and
the man-page. 

On the other hand, password rotation is a dead-end, and makes the
problem worse, see e.g.

 http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
 http://transvasive.com/index.php?option=com_content&id=46

The basic problem is that password rotation prevents the use
of good, harder to remember passwords, while at the same
time it does noting to increae security. Once somebody halfway
competent has broken in, they will put in their own backdoor anyways.
In the few instances I am subject to this stupid measure, I have taken
to just attach the number fo the month to the password.

The one enterprise feature that is important is a recovery 
password. For LUKS, this could be enforced either by policy, or 
by an adjusted set-up tool. For example, you could mandate that
keyslot 8 always needs to contain a company recovery password 
or that a long, random password has to be put into keyslot 8 
and then stored in a sealed envelope in a safe.

Arno

On Thu, Mar 07, 2013 at 03:27:56PM -0500, Jeff Diehl wrote:
> Is anyone aware of a product/tool that can manage LUKS credentials
> at an enterprise level.  More specifically, something that can deal
> with things like password rotation.
> 
> --
> JD
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

Re: [dm-crypt] LUKS credential management at an enterprise level

[Jeff Diehl]

On 3/7/2013 4:17 PM, Arno Wagner wrote:
> In principle, any tool that can reasonably interface to
> a commandline interface can do this, see the FAQ and
> the man-page.
>

Thanks.  I did note that this was an option.

> On the other hand, password rotation is a dead-end, and makes the
> problem worse, see e.g.
>
>   http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
>   http://transvasive.com/index.php?option=com_content&id=46
>
> The basic problem is that password rotation prevents the use
> of good, harder to remember passwords, while at the same
> time it does noting to increase security. Once somebody halfway
> competent has broken in, they will put in their own backdoor anyways.
> In the few instances I am subject to this stupid measure, I have taken
> to just attach the number of the month to the password.
>

I probably should have made clear early on that the machines I am 
interested in managing are not end-user machines. They are a set of 
"servers" in a data center. I am looking for "enterprise" features that 
would allow me to manage LUKS credentials for a group of machines (~50 
boxen). These machines are not restarted with any frequency and the LUKS 
credentials are only ever needed by an authorized system administrator 
after a reboot. For various compliance reasons outside of my control, 
password rotation is required. In addition, I occasionally have a need 
to update/modify LUKS passwords for this group of machines on-demand 
(e.g. exiting an employee).  Managing the machines individually is 
possible but cumbersome and before creating a "home-grown" solution, I 
wanted to see if there was something already available.

> The one enterprise feature that is important is a recovery
> password. For LUKS, this could be enforced either by policy, or
> by an adjusted set-up tool. For example, you could mandate that
> keyslot 8 always needs to contain a company recovery password
> or that a long, random password has to be put into keyslot 8
> and then stored in a sealed envelope in a safe.
>

Thanks.  We use a process very similar to this for recovery.

--
JD

Re: [dm-crypt] LUKS credential management at an enterprise level

[Arno Wagner]

On Thu, Mar 07, 2013 at 09:28:36PM -0500, Jeff Diehl wrote:
> On 3/7/2013 4:17 PM, Arno Wagner wrote:
> >In principle, any tool that can reasonably interface to
> >a commandline interface can do this, see the FAQ and
> >the man-page.
> >
> 
> Thanks.  I did note that this was an option.

It is also supported to do it that way, i.e. the 
commandline API stays stable if at all possible.
There are extensive explanations in the man page
on how to get things like passphrases in from outside,
precisely if you want to use cryptsetup from a script.

> >On the other hand, password rotation is a dead-end, and makes the
> >problem worse, see e.g.
> >
> >  http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
> >  http://transvasive.com/index.php?option=com_content&id=46
> >
> >The basic problem is that password rotation prevents the use
> >of good, harder to remember passwords, while at the same
> >time it does noting to increase security. Once somebody halfway
> >competent has broken in, they will put in their own backdoor anyways.
> >In the few instances I am subject to this stupid measure, I have taken
> >to just attach the number of the month to the password.
> >
> 
> I probably should have made clear early on that the machines I am
> interested in managing are not end-user machines. 

Ok, that is different.

> They are a set of
> "servers" in a data center. I am looking for "enterprise" features
> that would allow me to manage LUKS credentials for a group of
> machines (~50 boxen). These machines are not restarted with any
> frequency and the LUKS credentials are only ever needed by an
> authorized system administrator after a reboot.

Ok.

> For various
> compliance reasons outside of my control, password rotation is
> required. 

Well, yes. I know the problem. 

> In addition, I occasionally have a need to update/modify
> LUKS passwords for this group of machines on-demand (e.g. exiting an
> employee).  Managing the machines individually is possible but
> cumbersome and before creating a "home-grown" solution, I wanted to
> see if there was something already available.

I have done something a bit similar in the past for a
cimputer cluster. The simplest thing was to have a
machine that is allowed passwordless SSH-logins and
then just run the scripts on that machine and execute
them remotely via SSH, i.e. instead of having in you script
  "cryptsetup <something>" on the machine itself
use 
  "ssh root@machine \"cryptsetup <something>\""

You can even pipe things into stdin of the command
that way:

  echo "blablubb" | ssh root@machine "| <command that gets the input"

You can also get the "machine" part from a list,
via the commandline, or however you prefer.
I found that this works really well and I had 
things like user account creation, etc. working after
a day for about 25 machines (20 of them very similar though).
Unless you do really complex stuff, this should take
not too long to run even for 50 machines. 

What is needed is one machine you trust that gets the 
password-less SSH login. This can be a laptop that
is locked away when not used or the like or even a bootable
USB disk with, say, Knoppix and your scripts on it
(and all data can be in an encrypted partition on that
Knoppix stick.).
You also need to take into account that password-less
login is actually more secure if you can secure the
point it is coming from, as it uses 2-sided authentication 
after the first login.


As to changes, manipulating the LUKS header via cryptsetup
is no problem at all while the LUKS container is mapped. So 
you can remove/change a credential in a key-slot at any time 
with one call to cryptsetup. Also note that any tool that did 
this for you would have to go through the cryptsetup commandline 
tool (easy) or the cryptsetup library (harder) anyways,
but I am not aware of any such management solutions with
cryptsetup support.

> >The one enterprise feature that is important is a recovery
> >password. For LUKS, this could be enforced either by policy, or
> >by an adjusted set-up tool. For example, you could mandate that
> >keyslot 8 always needs to contain a company recovery password
> >or that a long, random password has to be put into keyslot 8
> >and then stored in a sealed envelope in a safe.
> >
> 
> Thanks.  We use a process very similar to this for recovery.

Ok, so you get it then. No need for me to comment any futher.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell