[dm-crypt] LUKS credential management at an enterprise level
arno at wagner.name
Fri Mar 8 05:29:51 CET 2013
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.
> For various
> compliance reasons outside of my control, password rotation is
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
"ssh root at machine \"cryptsetup <something>\""
You can even pipe things into stdin of the command
echo "blablubb" | ssh root at 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
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
> >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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt