Re: LUKS credential management at an enterprise level

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux