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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
