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
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.
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.