Re: dm-crypt crypt_status reports key?

[Matt Mackall <mpm@selenic.com>]

On Wed, Feb 02, 2005 at 11:50:02PM +0000, Alasdair G Kergon wrote:
> On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote:
> > # dmsetup table /dev/mapper/volume1
> > 0 2000000 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
>  
> > Obviously, root can in principle recover this password from the
> > running kernel but it seems silly to make it so easy.
>  
> There seemed little point obfuscating it - someone will only
> write a trivial utility that recovers it.

So instead let's do the work for them? We could perhaps put it in the
root prompt. Pray tell, what is the value to the user of exposing the
whole password, ever?

> Consider instead *why* you're worried about the password being
> held in RAM and look for better solutions to *your*
> perceived threats.

My perceived threat, as I've already stated, is that automated suite
of utilities like LVM or EVMS or even initscripts will silently store
this information in the clear on disk in an effort to make life
easier, oblivious to the fact that it might contain security-sensitive
information.

What drives this perception is that the output of "dmsetup tables"
invites it: it appears tailor-made to be fed into a future "dmsetup
create". Thus someone clever (but unaware of dm_crypt) _will_
eventually try this if it's not already happening. Further, there is
nothing in the dmsetup manpage to suggest that its output should be
guarded, etc. See "principle of least surprise."

Given the potential risk of naive use of dmsetup tables, what's the
upside again?

-- 
Mathematics is the supreme nostalgia of our time.