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
> 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
annoying - it makes rescue mode useless in the default case.
Yeah, I agree that the issue is annoying and real.