[dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell
rnicholsNOSPAM at comcast.net
Tue Nov 15 23:51:15 CET 2016
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.
More information about the dm-crypt