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

[Jeff Diehl <diehl.jeff@gmail.com>]

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