From: Olivier Sessink <oliviersessink@gmail.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] encrypted root: prevent / detect tampering with kernel / initrd
Date: Mon, 28 Dec 2009 22:41:04 +0100 [thread overview]
Message-ID: <4B3925F0.4050409@gmail.com> (raw)
In-Reply-To: <20091228212038.GB2224@maude.comedia.it>
Luca Berra wrote:
> On Mon, Dec 28, 2009 at 09:28:43PM +0100, Olivier Sessink wrote:
>> Hi all,
>>
>> I was wondering if there are some 'common' ways to prevent tampering
>> with the unencrypted kernel and initrd in the case of an encrypted
>> root filesystem? If somebody has access to your computer they could
>> change the initrd and kernel and make your encryption useless (e.g.
>> store the password in /boot, or send it over the network, etc. etc.).
>> It shouldn't be too hard to make this at least very difficult.
>
> I'm sorry if anyone has physical access to the machine, you lose.
> there is nothing you can do to prevent it.
> If your laptop is stolen and later found, i would not trust typing my
> password again booting from that disk. I would boot from a rescue media
> or install the disk in another machine and recover the data.
> What you suggest only creates a false sense of security and should be
> avoided.
yes you are 100% right from a perfect security viewpoint. However, we're
looking at a "regular user" deployment, and we know that our regular
users are not going to look after their devices as good as most IT
security professionals will do (they might even carry their password in
their wallet, or tell the password over the phone). So our aim is not
100% perfect security, but just "make it (a lot) harder" to get to the
data.
The data on the devices is interesting enough for a simple hack, but not
interesting enough for a very complicated attack (or a physical
keylogger or tempest attack). So if we can avoid the simple attacks we
have improved the overall security.
So in our not-so-perfect world we will loose from a determined hacker
anyway. But perhaps we can be safe from the script kiddies.
Olivier
next prev parent reply other threads:[~2009-12-28 21:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-28 20:28 [dm-crypt] encrypted root: prevent / detect tampering with kernel / initrd Olivier Sessink
2009-12-28 21:20 ` Luca Berra
2009-12-28 21:41 ` Olivier Sessink [this message]
2009-12-28 23:11 ` Heinz Diehl
2009-12-29 10:05 ` Olivier Sessink
2009-12-29 10:23 ` [lesh] Ivan Nikolic
2009-12-29 12:25 ` Olivier Sessink
2009-12-29 12:37 ` Milan Broz
2009-12-29 20:24 ` Arno Wagner
2009-12-29 21:15 ` Heinz Diehl
2009-12-29 23:02 ` Olivier Sessink
2009-12-30 2:52 ` Arno Wagner
2009-12-30 14:16 ` Heinz Diehl
2009-12-30 15:34 ` Arno Wagner
2009-12-29 21:31 ` Hannes Erven
2009-12-29 21:41 ` Gregy
2009-12-30 2:53 ` Arno Wagner
2009-12-28 22:41 ` Zdenek Kaspar
2009-12-28 22:51 ` Zdenek Kaspar
2009-12-28 22:57 ` Heinz Diehl
2009-12-29 20:18 ` Arno Wagner
2009-12-29 22:52 ` Olivier Sessink
2009-12-30 2:56 ` Arno Wagner
2009-12-30 10:48 ` Olivier Sessink
2009-12-30 15:28 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B3925F0.4050409@gmail.com \
--to=oliviersessink@gmail.com \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.