From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 27 Oct 2016 01:33:30 +0200 (CEST) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bzXSI-000614-UU for dm-crypt@saout.de; Thu, 27 Oct 2016 01:17:58 +0200 From: Robert Nichols Date: Wed, 26 Oct 2016 18:17:42 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [dm-crypt] pashphrase management question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 10/26/2016 11:43 AM, ClEmFoster wrote: > hello, > > The setup: > > I work in an environment that has a whole disk encryption requirement for > VMs. If the VM is restarted an admin has to hit the console and type in > the passphrase to boot. This is OK, we don't reboot much, and security > guys are happy. The problem is they are going to start requiring that > these machines also receive a passphrase change every 3 or 6 months. That > brings me to the question. Are "they" aware that anyone who has had read access to the device with the LUKS container has had an opportunity to copy the LUKS header, and can always use that LUKS header with the old passphrase to unlock the container (perhaps after spending however much time and processing power is needed to crack that passphrase offline). For that matter, anyone with root access to the VM while the LUKS container is unlocked can easily obtain the master key (dmsetup table --showkeys /dev/{whatever}) and can always access the LUKS container with that. Changing the passphrase doesn't protect against any of that. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.