All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 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.