On Tue, Dec 07, 2021 at 12:01:32PM +0000, Richard W.M. Jones wrote: > 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? There are many many different ways in which systems are installed, but the general principle is that one the system is up, you need valid credentials to log in. So protecting the system before it's running, i.e. protecting the data at rest, can be done in many different ways and is your responsibility, after it is up, you know that the normal system mechanisms apply. With the proposal this promise is broken. Having the root account locked just avoid violating that promise. One trivial example: a kiosk where you can type on the keyboard, but can't physically touch the machine, and the boot loader is locked down. With the proposed change, if you can affect the system so that it does not boot properly, even by causing a sufficient delay, is enough to get unrestricted access. > On the flip side I have hit the problem described and it's incredibly > annoying - it makes rescue mode useless in the default case. Yeah, I agree that the issue is annoying and real. Zbyszek _______________________________________________ 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
