Bug 19800

Although the actual shell script should also be "fixed", an example patch is available via http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

CC: (none) => doktor5000, mageia

That patch only applies to Debian.  Supposedly dracut has something with a similar bug, but it's not the same code.

thierry, martin, 

any comment about https://bugzilla.redhat.com/show_bug.cgi?id=1395135#c3 ?

Assignee: thierry.vignaud => mageiatools
CC: (none) => mageia

In my opinion, this issue is about user education.

Forcing the use of rd.shell=0 when encrypting the root file system has implications in recovering from things like a power failure leaving the
root file system requiring manual repair. Without testing, I'm not sure
if the failure to mount after decrypting would then prevent booting or not.
As such, adding the option to add rd.shell=0 when choosing to encrypt the
root file system should be considered for a future enhancement.

Adding a grub password is a good recommendation, though it should be entirely
the admin's choice.

Adding a bios/uefi password is beyond the scope of software. It's a good suggestion, where the potential attacker has physical access, though it
doesn't prevent them from physically destroying the hard drive. Same with
the usually related security suggestion to block booting from removable media.

Even though cves have been assigned, I don't consider this to be a security
issue, or worthy of being considered as a potential release blocker.

CC: (none) => davidwhodgins

An according to the council meeting, user education can start with errata.  Can someone that understands this write an erratum entry for this?

Keywords: (none) => FOR_ERRATA6

Added a Security issues section in errata
https://wiki.mageia.org/en/Mageia_6_Errata#Security_issues

Boot of system with cyphered partitions - CVE-2016-4484

Failed tries to enter the password of a cyphered partition with LUKS end with a shell. http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

People who want to secure their system have to:

    add a BIOS password
    add a grub password
    add “rd.shell=0” to the kernel command line

CC: (none) => yves.brungard_mageia

Removing MGA5TOO, since this won't be addressed there.

Whiteboard: MGA6TOO, MGA5TOO => MGA6TOO

to test this CVE: 

http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

Why not adding rd.shell=0 to Kernel command line when user wants a GRUB password like Fedora does with Anaconda?

Updating SRPM version number.

Until this, errata for this from M6 should be also part of Erratas M7 and M8.

CC: (none) => ouaurelien
Source RPM: dracut-044-11.mga6.src.rpm => dracut-051-4.mga8.src.rpm

Martin, Thomas,

what do you think about this one ?

Didnt see this until now.
Per comment 10 for errata

CC: (none) => fri
Keywords: (none) => FOR_ERRATA7, FOR_ERRATA8

https://wiki.mageia.org/en/Mageia_7_Errata#Security
https://wiki.mageia.org/en/Mageia_8_Errata#Security

This bug makes it easy to destroy things, but the encrypted content is still encrypted.
So encryption is still good enough for must use cases IMO.

Keywords: FOR_ERRATA7, FOR_ERRATA8 => IN_ERRATA7, IN_ERRATA8

Removing Mageia 7 from whiteboard due to EOL:
https://blog.mageia.org/en/2021/06/08/mageia-7-will-reach-end-of-support-on-30th-of-june-the-king-is-dead-long-live-the-king/

Whiteboard: MGA7TOO, MGA8TOO => MGA8TOO

Removing Mageia 8 from whiteboard due to EOL!

CC: (none) => geiger.david68210
Target Milestone: Mageia 8 => Mageia 9
Whiteboard: MGA8TOO => MGA9TOO

It is since long also in mga9 errata
https://wiki.mageia.org/en/Mageia_9_Errata#Security

Target Milestone: Mageia 9 => Mageia 10
Keywords: (none) => IN_ERRATA9