Am 15.11.2016 um 20:19 schrieb Robert Nichols:
On 11/15/2016 12:40 PM, Sven Eschenberg wrote:
Am 15.11.2016 um 16:18 schrieb Robert Nichols:
On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
Obviously it is not a bug in cryptsetup, but rather in dracut and some
distributions initrd scripts. What's really annoying about the CVE is
the fact, that it is mostly irrelevant. If I can get to the password
entry of an initrd, I obviously have control over the boot process.
If I
do have control over the boot process I have a splendid variety of
options to do all the things described in the CVE.
I wonder why the authors of the CVE recommend to freeze the system,
instead of adding auth to get a shell. Seems quite stupid to completely
remove the ability to investigate problems.
The boot process can be configured to deny that control (BIOS configured
to boot from the internal drive only, GRUB set up to require a password
for all except the default selection).
Interesting, haven't seen any such firmware so far for PC. A firmware
that indeed can disable the bootmenu etc. whilst not requiring a
password during boot would be the one exception of course.
Most firmwares will actually happily boot the configured port, even when
the device is switched over, with one exception: Secure Boot with a
uniquely signed bootloader and a unique key installed in the firmware.
(Requires a non vendor key).
The machines I have all either (a) if a BIOS administrator password is
set, requires that password in order to enter the boot menu, or (b)
allow all alternative devices to be excluded as boot device candidates.
Either way, you need the BIOS administrator password to get to an
alternative boot device.
Surprisingly this seems to be the case for the machine I just tested.
I'd assume an extra option+PW for the boot menu however, since it is not
a direct access to the setup nor a persistent change. So, yes, admitted,
with an admin PW one can get all the way to the initram without entering
an extra password. I wonder however how securely that password is stored?
On a Red Hat system with an encrypted root filesystem, I get 5 attempts
to enter the encryption password. Then the system locks up, and the only
options are to (a) press <ESC> to dismiss the graphical boot screen and
see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.
I'm still considering this a stupid approach, I prefer a sulogin with
auth approach and happily live with it.
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.
-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
