On Tue, Dec 07, 2021 at 11:26:37AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote: > > This does not pose an increased security risk: - [if] you can already > > boot with init=/sysroot/bin/bash anyway - anyone with physical > > access to a machine can probably compromise it - you can enforce the > > need for a root password in single-user mode by setting it I don't understand this bit: > I disagree with the assessment. There are at least two important cases > where the assumption that anyone with local access can escalate to > full access does not hold. If the data is encrypted, then being able > to override the init doesn't achieve anything, until the decryption > has been performed. How does the locked root account make anything more secure in this case? > The second case is when the admin has actually > locked down the kernel command line and relies on the normal > authentication mechanisms to protect the system. In both cases your > proposal creates an additional method of attack that activates at a > later point where the system is already running and the integrity of > the system must be maintained to protect unencrypted data. With the > proposal, any mechanism which leads to the system entering emergency > mode results in a compromise. Again, if you have the LUKS password you can easily mount the disk and make any changes you like. How does the locked root account help? On the flip side I have hit the problem described and it's incredibly annoying - it makes rescue mode useless in the default case. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
