From: Robert Nichols <rnicholsNOSPAM@comcast.net>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell
Date: Tue, 15 Nov 2016 16:51:15 -0600 [thread overview]
Message-ID: <o0g3h0$8cd$1@blaine.gmane.org> (raw)
In-Reply-To: <2aa32b7a-8aa4-bd7a-c6f0-eaef3794e8e8@whgl.uni-frankfurt.de>
On 11/15/2016 01:42 PM, Sven Eschenberg wrote:
>
>
> Am 15.11.2016 um 20:19 schrieb Robert Nichols:
>> sulogin is going to be hard to do if the root filesystem (where
>> /etc/shadow resides) has not been decrypted. You would have to have some
>> alternative password mechanism, and you can already accomplish that in
>> GRUB with password-protected alternatives.
>>
>
> No, the root filesystem is the initram (initrd) until rootfs is switched
> over - all you have to do is adding a passwd(file) with an entry to it.
> You won't need shadow anyway, since the only login supported is a root
> login, which implies full access to shadow (usually). Of course you
> would probably not want to just grep the root line from the system, but
> generate a single line passwd(file) with an entry for root with some
> seperate password. If you trust on the cryptographic strength of the
> hashing and salting in the passwd/shadow files, you could include them
> aswell and support user and root logins with sulogin (during initrd).
> Using shadow in this particular case makes sense again.
As I said, "some alternative password mechanism."
FWIW in Red Hat systems, at least, there are several values you can pass
for "rdbreak=" in the boot parameters that will cause the initrd script
to drop into a debug shell before the decryption password is ever
requested. It is a long-standing truism that without physical security,
there is no protection for unencrypted storage on the system.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
next prev parent reply other threads:[~2016-11-15 22:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 12:34 [dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell Milan Broz
2016-11-15 13:27 ` Arno Wagner
2016-11-15 13:32 ` Sven Eschenberg
2016-11-15 15:18 ` Robert Nichols
2016-11-15 18:40 ` Sven Eschenberg
2016-11-15 19:19 ` Robert Nichols
2016-11-15 19:42 ` Sven Eschenberg
2016-11-15 22:51 ` Robert Nichols [this message]
2016-11-15 23:15 ` Michael Kjörling
2016-11-15 23:28 ` Sven Eschenberg
2016-11-15 23:52 ` Arno Wagner
2016-11-16 0:08 ` Jonas Meurer
2016-11-16 1:15 ` Sven Eschenberg
2016-11-16 7:32 ` Milan Broz
2016-11-16 13:48 ` Arno Wagner
2016-11-29 14:56 ` David Niklas
2016-12-07 11:37 ` Jonas Meurer
2016-12-07 13:00 ` 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='o0g3h0$8cd$1@blaine.gmane.org' \
--to=rnicholsnospam@comcast.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox