F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/FixRescueMode

== Summary ==
Fedora defaults to locking the root account, which is needed by
single-user mode. This Change uses `sulogin --force` so the password
request is bypassed under this circumstance.

== Owner ==
* Name: [[User:Salimma|Michel Alexandre Salim]]
* Email: michel(a)michel-slm.name
* Name: [[User:Ngompa|Neal Gompa]]
* Email: ngompa13(a)gmail.com
* Name: [[User:Davdunc|David Duncan]]
* Email: davdunc(a)amazon.com


== Detailed Description ==
Users typically only use single-user mode in case the normal boot is
not working. In the unfortunate situation that it happens, under the
current setup they cannot recover without booting from a Fedora live
image or another image, or by overriding `init=`, because our
single-user mode requires a root password, and by default we lock the
root account.

A more user-friendly setup is to allow the password to be bypassed in
case it's not set.

This does not pose an increased security risk:
- 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

This change will be implemented by pre-installing an RPM containing
systemd overrides for `emergency.service` and `rescue.service`,
similar to the
[https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b4539023...
CoreOS implementation], so users and editions/variants can opt out by
removing this or omitting it from their default installation.


== Benefit to Fedora ==
This Change provides a better out-of-the-box user experience in case
they need to rescue their system, by making the rescue option
presented in the bootloader actually work.

== Scope ==
* Proposal owners: Ship the needed configuration change in a systemd
subpackage. Test and verify that it works, then work with editions and
spins to test and enable this by default by making `systemd`
`Recommends: (systemd-rescue-defaults if dracut-config-rescue)`
* Other developers: Test this and opt-out if necessary (eg cloud
doesn't have a rescue initramfs so the package is deadweight). On
variants where dracut-config-rescue is installed but an opt out is
desired, excluding the package from installation will prevent it being
installed on systemd upgrades
* Release engineering: [https://pagure.io/releng/issue/10422 #10422]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
Upgrades would pull in this automatically, see
[https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect]

== How To Test ==
- `dnf install systemd-rescue-defaults`
- reboot and verify rescue mode works

== User Experience ==
Rescue mode works out of the box, without resorting to overriding
init= or using a live media.

== Dependencies ==
- most changes will be done in the `systemd` package
- for variants that need to opt out we'll need to modify their kickstart files

== Contingency Plan ==

* Contingency mechanism: if the `Recommends` have been added to
systemd, remove it and potentially add an `Obsoletes:` to remove older
known-bad versions of `rescue-defaults`
* Contingency deadline: Beta freeze
* Blocks release? No

== Documentation ==
The built-in rescue mode now works out of the box without needing to
use a live image. For added security you can set a root password.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Chris Adams]

Once upon a time, Ben Cotton <bcotton(a)redhat.com&gt; said:
>  https://fedoraproject.org/wiki/Changes/FixRescueMode
>  
>  == Summary ==
>  Fedora defaults to locking the root account, which is needed by
>  single-user mode. This Change uses `sulogin --force` so the password
>  request is bypassed under this circumstance. 
Thanks!
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
>  Fedora defaults to locking the root account, which is needed by
>  single-user mode. This Change uses `sulogin --force` so the password
>  request is bypassed under this circumstance. 
I think this is a terrible idea. The problem is real, but this
solution addresses it in the wrong place. Essentially, you are proposing
a behaviour of "something is wrong, let's make everything open without
authentication", which is good for debugging and development, but not
acceptable for a real system.

The correct solution is to enhance login mechanisms so that it is
possible to authenticate using existing credentials also in the rescue
mode. The fact that this is not possible right now is a bug that needs
to be fixed.

There are two features (in the sense of bits of technology) which we
didn't have in the past and which will most likely should be part of
the solution. The first is yescrypt/argon2 hashing for functions: the
complexity of brute-forcing such passwords is high enough that a
password of sufficient length should be safe even if the hash is
exposed (i.e. the passwd/shadow split is not important anymore). This
means that we can consider embedding a password somewhere in the initrd
or elsewhere in the unencrypted storage.

The second is using tpm2 for protection of local secrets: the tpm2
can enforce limits on brute-force attacks on the password.

So we have some mechanisms to reasonably store a password in boot
configuration outside of the encrypted file systems. What we currently
don't have is a mechanism to make use of it, and a mechanism to update
the password.

I would expect a solution along those lines: when initially installing
a system using Anaconda and setting the root password, or when setting/updating
the password at some later point, if the user in question has admin
privileges (is root or e.g. is part of the wheel group), propagate the
yescrypted password to some accessible-at-boot-time storage. On EFI
systems that would most likely be some EFI variable. If available, use
the TPM2 to additionally tie the password to local hardware. If the
user is removed, also remove that password from that storage.

During boot, if it is necessary to authenticate before the root file
system has been mounted, allow admin users to log in using the credentials
that were stored previously.

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

Zbyszek

[Richard W.M. Jones]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Vít Ondruch]

Dne 07. 12. 21 v 12:26 Zbigniew Jędrzejewski-Szmek napsal(a):
>  On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> > Fedora defaults to locking the root account, which is needed by
> > single-user mode. This Change uses `sulogin --force` so the password
> > request is bypassed under this circumstance.
>  I think this is a terrible idea. The problem is real, but this
>  solution addresses it in the wrong place. Essentially, you are proposing
>  a behaviour of "something is wrong, let's make everything open without
>  authentication", which is good for debugging and development, but not
>  acceptable for a real system.
>  

I think that while ago, I have already proposed to drop the rescue mode 
altogether, because ATM, it just makes things worse. If I cannot 
regularly boot and I open rescue mode, then I am asked for root 
password, which is not set. That is like adding salt into injury.


>  The correct solution is to enhance login mechanisms so that it is
>  possible to authenticate using existing credentials also in the rescue
>  mode. The fact that this is not possible right now is a bug that needs
>  to be fixed.
>
>  There are two features (in the sense of bits of technology) which we
>  didn't have in the past and which will most likely should be part of
>  the solution. The first is yescrypt/argon2 hashing for functions: the
>  complexity of brute-forcing such passwords is high enough that a
>  password of sufficient length should be safe even if the hash is
>  exposed (i.e. the passwd/shadow split is not important anymore). This
>  means that we can consider embedding a password somewhere in the initrd
>  or elsewhere in the unencrypted storage.
>
>  The second is using tpm2 for protection of local secrets: the tpm2
>  can enforce limits on brute-force attacks on the password.
>
>  So we have some mechanisms to reasonably store a password in boot
>  configuration outside of the encrypted file systems. What we currently
>  don't have is a mechanism to make use of it, and a mechanism to update
>  the password.
>
>  I would expect a solution along those lines: when initially installing
>  a system using Anaconda and setting the root password, or when setting/updating
>  the password at some later point
>  

You have probably meant s/root/user with admin privileges/ ?


>  , if the user in question has admin
>  privileges (is root or e.g. is part of the wheel group), propagate the
>  yescrypted password to some accessible-at-boot-time storage. On EFI
>  systems that would most likely be some EFI variable. If available, use
>  the TPM2 to additionally tie the password to local hardware. If the
>  user is removed, also remove that password from that storage.
>
>  During boot, if it is necessary to authenticate before the root file
>  system has been mounted, allow admin users to log in using the credentials
>  that were stored previously.
>  

Is this being worked on? Do you have any references?


Vít


> > 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 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. 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.
>
>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 03:41:02PM +0100, Vít Ondruch wrote:
>  
>  Dne 07. 12. 21 v 12:26 Zbigniew Jędrzejewski-Szmek napsal(a):
>  >On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
>  >>Fedora defaults to locking the root account, which is needed by
>  >>single-user mode. This Change uses `sulogin --force` so the password
>  >>request is bypassed under this circumstance.
>  >I think this is a terrible idea. The problem is real, but this
>  >solution addresses it in the wrong place. Essentially, you are proposing
>  >a behaviour of "something is wrong, let's make everything open without
>  >authentication", which is good for debugging and development, but not
>  >acceptable for a real system.
>  
>  
>  I think that while ago, I have already proposed to drop the rescue mode
>  altogether, because ATM, it just makes things worse. If I cannot regularly
>  boot and I open rescue mode, then I am asked for root password, which is not
>  set. That is like adding salt into injury.
>  
>  
>  >
>  >The correct solution is to enhance login mechanisms so that it is
>  >possible to authenticate using existing credentials also in the rescue
>  >mode. The fact that this is not possible right now is a bug that needs
>  >to be fixed.
>  >
>  >There are two features (in the sense of bits of technology) which we
>  >didn't have in the past and which will most likely should be part of
>  >the solution. The first is yescrypt/argon2 hashing for functions: the
>  >complexity of brute-forcing such passwords is high enough that a
>  >password of sufficient length should be safe even if the hash is
>  >exposed (i.e. the passwd/shadow split is not important anymore). This
>  >means that we can consider embedding a password somewhere in the initrd
>  >or elsewhere in the unencrypted storage.
>  >
>  >The second is using tpm2 for protection of local secrets: the tpm2
>  >can enforce limits on brute-force attacks on the password.
>  >
>  >So we have some mechanisms to reasonably store a password in boot
>  >configuration outside of the encrypted file systems. What we currently
>  >don't have is a mechanism to make use of it, and a mechanism to update
>  >the password.
>  >
>  >I would expect a solution along those lines: when initially installing
>  >a system using Anaconda and setting the root password, or when setting/updating
>  >the password at some later point
>  
>  
>  You have probably meant s/root/user with admin privileges/ ? 
I meant both: the root user and all other "admin-type" users.

(I don't think we should allow "normal" users to log in when the
machine is not fully up. They don't have administrative privileges
to fix things anyway. Skipping those users has the advantage that we
avoid exposing potentially weaker passwords (i.e. we can count on the
admin users to know to ensure password strength, but not so for the other
users necessarily), and we avoid frequent access to the storage.)

>  >, if the user in question has admin
>  >privileges (is root or e.g. is part of the wheel group), propagate the
>  >yescrypted password to some accessible-at-boot-time storage. On EFI
>  >systems that would most likely be some EFI variable. If available, use
>  >the TPM2 to additionally tie the password to local hardware. If the
>  >user is removed, also remove that password from that storage.
>  >
>  >During boot, if it is necessary to authenticate before the root file
>  >system has been mounted, allow admin users to log in using the credentials
>  >that were stored previously.
>  
>  
>  Is this being worked on? Do you have any references? 
Latest systemd versions have been getting some support for the low-level
parts, i.e. the low-level encrypted-secret storage. But we're missing the
upper parts, i.e. how to actually use and update the passwords. I didn't
even mention this, because we don't have a comprehensive story yet.
I think it'd be necessary to write some pam module and/or authentication
helper from scratch. It's probably not too much work, but nobody has
signed up to do this.

Zbyszek

[przemek klosowski]

On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:

> >>   If available, use
> >> the TPM2 to additionally tie the password to local hardware. If the
> >> user is removed, also remove that password from that storage.
> >>
> >> During boot, if it is necessary to authenticate before the root file
> >> system has been mounted, allow admin users to log in using the credentials
> >> that were stored previously.
> > Is this being worked on? Do you have any references?
>  Latest systemd versions have been getting some support for the low-level
>  parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  upper parts, i.e. how to actually use and update the passwords. I didn't
>  even mention this, because we don't have a comprehensive story yet. 
A scenario that wasn't mentioned here yet is using a disk from a failed 
system: either moving it to another system, or even simply accessing the 
data. If the credentials (including the LUKS encryption key/password) 
are protected by TPM2, it may effectively prevent any further access. It 
would be useful if any such new scheme avoided that.

In enterprise system, there usually is a backup decryption key, 
accessible to the enterprise admins. I am not sure what would be 
appropriate for single-user systems: some sort of install-time rescue 
passphrase [1] perhaps, that the user would write down and safely store [2]?

[1] https://xkcd.com/936/

[2] conveniently stored next to the rubber hose so that the attackers 
could forgo its use and type the rescue passphrase themselves. 
https://xkcd.com/538/

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 05:01:50PM -0500, przemek klosowski via devel wrote:
>  On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  >>>  If available, use
>  >>>the TPM2 to additionally tie the password to local hardware. If the
>  >>>user is removed, also remove that password from that storage.
>  >>>
>  >>>During boot, if it is necessary to authenticate before the root file
>  >>>system has been mounted, allow admin users to log in using the credentials
>  >>>that were stored previously.
>  >>Is this being worked on? Do you have any references?
>  >Latest systemd versions have been getting some support for the low-level
>  >parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  >upper parts, i.e. how to actually use and update the passwords. I didn't
>  >even mention this, because we don't have a comprehensive story yet.
>  
>  A scenario that wasn't mentioned here yet is using a disk from a failed
>  system: either moving it to another system, or even simply accessing the
>  data. If the credentials (including the LUKS encryption key/password) are
>  protected by TPM2, it may effectively prevent any further access. It would
>  be useful if any such new scheme avoided that. 
The recovery password is necessary for encrypted data. For a user account,
it could be useful, but is less necessary, because generally you're expected
to simply reset the password if lost.

Generally the idea is that you have a nice reasonable-to-type password that
is protected by the TPM, and in addition a second recovery key that
can be used in case the TPM croaks or the disk is moved.

systemd-cryptenroll and homectl support generation of such recovery keys [3,4].
In comparison to a password it is longer and generated from entropy instead
of entered by the user, so brute-force attacks are not a concern. It is
supposed to be written down or saved somewhere when initially creating
the encrypted storage.

>  In enterprise system, there usually is a backup decryption key,
> accessible
>  to the enterprise admins. I am not sure what would be appropriate for
>  single-user systems: some sort of install-time rescue passphrase [1]
>  perhaps, that the user would write down and safely store [2]?
>  
>  [1] https://xkcd.com/936/
>  
>  [2] conveniently stored next to the rubber hose so that the attackers could
>  forgo its use and type the rescue passphrase themselves.
>  https://xkcd.com/538/ 
That's a classic ;)

[3] https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html
[4] https://www.freedesktop.org/software/systemd/man/homectl.html

Zbyszek

[Vitaly Zaitsev]

On 07/12/2021 23:01, przemek klosowski via devel wrote:
>  I am not sure what would be appropriate for single-user systems: some
>
>  sort of install-time rescue passphrase [1] perhaps, that the user would 
>  write down and safely store [2]? 
This will be a potential backdoor.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Lennart Poettering]

On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:

>  Latest systemd versions have been getting some support for the
> low-level
>  parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  upper parts, i.e. how to actually use and update the passwords. I didn't
>  even mention this, because we don't have a comprehensive story yet.
>  I think it'd be necessary to write some pam module and/or authentication
>  helper from scratch. It's probably not too much work, but nobody has
>  signed up to do this. 
So here's what I'd suggest: let's define a group (my suggestion: let's
repurpose "wheel" for that) that has the effect that the passwords of
any user in it are also accepted as password for the root user,
implicitly. We'd have to add some small infra to collect these
passwords, and encrypt/sign them with TPM2, then propagate to the ESP
or to some EFI var or so, so that they can be honoured already in the
initrd.

With such a mechanism we would have quite nice semantics: if a user is
designated to have admin privs, then that's sufficient to be able to
log into the root account, no further manual work necessary, and it
applies to the whole runtime of the OS: from initrd to regular system,
to sudo.

Lennart

--
Lennart Poettering, Berlin

[Matthew Miller]

On Wed, Dec 08, 2021 at 01:50:47PM +0100, Lennart Poettering wrote:
>  So here's what I'd suggest: let's define a group (my
> suggestion: let's
>  repurpose "wheel" for that) that has the effect that the passwords of
>  any user in it are also accepted as password for the root user, 
My working real-world security knowledge is dangerously out of date so I will
defer to others on the proposal itself, but: yes, we already treat wheel
membership as "able to escalate to root", and it seems sane to reuse.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Alexander Bokovoy]

On ke, 08 joulu 2021, Matthew Miller wrote:
> On Wed, Dec 08, 2021 at 01:50:47PM +0100, Lennart Poettering wrote:
> > So here's what I'd suggest: let's define a group (my suggestion:
> let's
> > repurpose "wheel" for that) that has the effect that the passwords of
> > any user in it are also accepted as password for the root user,
>
> My working real-world security knowledge is dangerously out of date so I will
> defer to others on the proposal itself, but: yes, we already treat wheel
> membership as "able to escalate to root", and it seems sane to reuse. 
Since we have group merging in effect in glibc, please do not treat a
user present in wheel group but missing in /etc/shadow as something
extra-ordinary. It is a normal situation when you have users in the
centralized identity store like FreeIPA or Samba AD.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Chris Murphy]

On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
>
>  > Latest systemd versions have been getting some support for the low-level
>  > parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  > upper parts, i.e. how to actually use and update the passwords. I didn't
>  > even mention this, because we don't have a comprehensive story yet.
>  > I think it'd be necessary to write some pam module and/or authentication
>  > helper from scratch. It's probably not too much work, but nobody has
>  > signed up to do this.
>
>  So here's what I'd suggest: let's define a group (my suggestion: let's
>  repurpose "wheel" for that) that has the effect that the passwords of
>  any user in it are also accepted as password for the root user,
>  implicitly. We'd have to add some small infra to collect these
>  passwords, and encrypt/sign them with TPM2, then propagate to the ESP
>  or to some EFI var or so, so that they can be honoured already in the
>  initrd. 
I'm skeptical of any TPM2 dependency because systems still do not come
with them, in particular the significant minority of systems that are
not part of the "made for Windows" marketing program that compels
manufacturers to follow the Windows Hardware Compatibility Program.
And yes you can install Windows 11 without a TPM, it just won't be
preinstalled, and that make/model doesn't qualify for whatever Windows
marketing programs OEM's get for having certified hardware. That's
aside from the fact there's TPM 2.0 in hardware today that the kernel
doesn't support and likely won't ever support.


-- 
Chris Murphy

[Colin Walters]

On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote:
>  On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering
> <mzerqung(a)0pointer.de&gt; wrote:
> >
> > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
> >
> > > Latest systemd versions have been getting some support for the low-level
> > > parts, i.e. the low-level encrypted-secret storage. But we're missing the
> > > upper parts, i.e. how to actually use and update the passwords. I didn't
> > > even mention this, because we don't have a comprehensive story yet.
> > > I think it'd be necessary to write some pam module and/or authentication
> > > helper from scratch. It's probably not too much work, but nobody has
> > > signed up to do this.
> >
> > So here's what I'd suggest: let's define a group (my suggestion:
> let's
> > repurpose "wheel" for that) that has the effect that the passwords of
> > any user in it are also accepted as password for the root user,
> > implicitly. We'd have to add some small infra to collect these
> > passwords, and encrypt/sign them with TPM2, then propagate to the ESP
> > or to some EFI var or so, so that they can be honoured already in the
> > initrd.I mean in addition this is tantamount to moving `/etc/shadow` into the tpm,
> right?
>
>  I'm skeptical of any TPM2 dependency because systems still do not come
>  with them, in particular the significant minority of systems that are
>  not part of the "made for Windows" marketing program that compels
>  manufacturers to follow the Windows Hardware Compatibility Program.
>  And yes you can install Windows 11 without a TPM, it just won't be
>  preinstalled, and that make/model doesn't qualify for whatever Windows
>  marketing programs OEM's get for having certified hardware. That's
>  aside from the fact there's TPM 2.0 in hardware today that the kernel
>  doesn't support and likely won't ever support. 
Right.  I am in favor of having tight integration with the TPM of course, but it can't
be used exclusively.

In particular, I think about half the posters in this thread are thinking of the desktop
case, but the problem can easily happen on virtualized servers too - that's why we
ship the bits we do in Fedora CoreOS.  And we need to consider public and private cloud
(e.g. OpenStack/vSphere) instances which were provisioned without UEFI, as well as ppc64le
and s390x.  And still today, the default for `virt-install` on x86_64 is BIOS.

So I'll just re-surface my idea of having the bootloader either pass information about
its "locked" state to the kernel and to systemd, or have some sort of more
declarative easily parsable config file for this that systemd could read (i.e. not
`grub.cfg`).  The former seems better.  Either way there's just one "source of
truth" and admins who *do* want to lock the system against casual keyboard
interactive changes don't need to do it in two places.

[Lennart Poettering]

On Mi, 08.12.21 18:10, Colin Walters (walters(a)verbum.org) wrote:

>  Right.  I am in favor of having tight integration with the TPM of
>  course, but it can't be used exclusively.
>
>  In particular, I think about half the posters in this thread are
>  thinking of the desktop case, but the problem can easily happen on
>  virtualized servers too - that's why we ship the bits we do in
>  Fedora CoreOS.  And we need to consider public and private cloud
>  (e.g. OpenStack/vSphere) instances which were provisioned without
>  UEFI, as well as ppc64le and s390x.  And still today, the default
>  for `virt-install` on x86_64 is BIOS.
>
>  So I'll just re-surface my idea of having the bootloader either pass
>  information about its "locked" state to the kernel and to systemd,
>  or have some sort of more declarative easily parsable config file
>  for this that systemd could read (i.e. not `grub.cfg`).  The former
>  seems better.  Either way there's just one "source of truth" and
>  admins who *do* want to lock the system against casual keyboard
>  interactive changes don't need to do it in two places. 
In recent sd-stub (i.e. the EFI stub shipped with systemd that you can
glue in front of an ELF kernel to make it an UEFI PE binary with
various nice benefits) added support for loading some select files off
the ESP, wrap them in an on-the-fly generated cpio archive and pass
them on to the invoked Linux kernel as additional initrd. This is
extremely easy to do (because cpio is so easy, it's a bunch of ASCII
characters in front of each file), and is how I would recommend
passing additional possibly even dynamic data from boot loader to the
initrd environment. sd-stub does this for two purposes: to provide
encrypted/authenticated "credentials" (which are passwords, iscsi
passphrases, SSL certificates, whatever you need, optionally bound to
TPM2), and to provide systemd extensions (which are verity
enabled/signed disk images that can be overlayed over OS fs trees, and
which we intend to use to implement trusted, immutable, vendor
initrds).

Providing additional resources from boot loaders to initrd
environments this way has the major benefit that it just appears in
the fs, i.e. accessible via fs API, is very simple to do, doesn't
require explicit new infra anywhere in the boot chain in between.

sd-stub/sd-boot implement this as mentioned, with the upcoming systemd
250. Legacy boot loaders such as grub could support that too.

Lennart

--
Lennart Poettering, Berlin

[Lennart Poettering]

On Mi, 08.12.21 13:28, Chris Murphy (lists(a)colorremedies.com) wrote:

>  On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering
> <mzerqung(a)0pointer.de&gt; wrote:
>  >
>  > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
>  >
>  > > Latest systemd versions have been getting some support for the low-level
>  > > parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  > > upper parts, i.e. how to actually use and update the passwords. I didn't
>  > > even mention this, because we don't have a comprehensive story yet.
>  > > I think it'd be necessary to write some pam module and/or authentication
>  > > helper from scratch. It's probably not too much work, but nobody has
>  > > signed up to do this.
>  >
>  > So here's what I'd suggest: let's define a group (my suggestion:
> let's
>  > repurpose "wheel" for that) that has the effect that the passwords of
>  > any user in it are also accepted as password for the root user,
>  > implicitly. We'd have to add some small infra to collect these
>  > passwords, and encrypt/sign them with TPM2, then propagate to the ESP
>  > or to some EFI var or so, so that they can be honoured already in the
>  > initrd.
>
>  I'm skeptical of any TPM2 dependency because systems still do not come
>  with them, in particular the significant minority of systems that are
>  not part of the "made for Windows" marketing program that compels
>  manufacturers to follow the Windows Hardware Compatibility Program. 
Well, I am pretty sure we should design our stuff with modern hw in
mind, i.e. design from the current state of the art of hardware, and
find graceful fallbacks for environments that are more limited. Yes, I
am fully aware that there are older and simpler devices that lack it,
but I don't think this should mean "don't use TPM2 by default", but
instead "let's use TPM2 whenever we can, but gracefully degrade if we
can't".

Or more specifically in this context: if we don't have a TPM2 chip,
we can't encrypt or authenticate the root passwords before allowing
them in the initrd. Which then means we won't do that in that case, so
things will still work, but of course you'll get much weaker security
guarantees.

>  And yes you can install Windows 11 without a TPM, it just won't
> be
>  preinstalled, and that make/model doesn't qualify for whatever Windows
>  marketing programs OEM's get for having certified hardware. That's
>  aside from the fact there's TPM 2.0 in hardware today that the kernel
>  doesn't support and likely won't ever support. 
Still, don't make this an exercise of racing to the bottom. Let's
focus on the future, be secure by default there, and provide
acceptable fallbacks for the past.

Lennart

--
Lennart Poettering, Berlin

[Vitaly Zaitsev]

On 09/12/2021 15:32, Lennart Poettering wrote:
>  TPM2 chip
>  you'll get much weaker security guarantees 
https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-netwo...

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[przemek klosowski]

On 12/9/21 10:15, Vitaly Zaitsev via devel wrote:
>  On 09/12/2021 15:32, Lennart Poettering wrote:
> > TPM2 chip you'll get much weaker security guarantees
>
>
> https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-netwo...
The Lenovo TPM implementation exploited here did not use TPM traffic 
encryption so the attackers simply eavesdropped on the traffic to the 
TPM during the boot.  As the article says, the TPM2 standard specifies 
traffic encryption that would have prevented that attack.

[Neal Gompa]

On Sat, Dec 11, 2021 at 9:43 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:
>  >
>  > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
>  >
>  > > Latest systemd versions have been getting some support for the low-level
>  > > parts, i.e. the low-level encrypted-secret storage. But we're missing the
>  > > upper parts, i.e. how to actually use and update the passwords. I didn't
>  > > even mention this, because we don't have a comprehensive story yet.
>  > > I think it'd be necessary to write some pam module and/or authentication
>  > > helper from scratch. It's probably not too much work, but nobody has
>  > > signed up to do this.
>  >
>  > So here's what I'd suggest: let's define a group (my suggestion:
> let's
>  > repurpose "wheel" for that) that has the effect that the passwords of
>  > any user in it are also accepted as password for the root user,
>  > implicitly. We'd have to add some small infra to collect these
>  > passwords, and encrypt/sign them with TPM2, then propagate to the ESP
>  > or to some EFI var or so, so that they can be honoured already in the
>  > initrd.
>
>  I'm skeptical of any TPM2 dependency because systems still do not come
>  with them, in particular the significant minority of systems that are
>  not part of the "made for Windows" marketing program that compels
>  manufacturers to follow the Windows Hardware Compatibility Program.
>  And yes you can install Windows 11 without a TPM, it just won't be
>  preinstalled, and that make/model doesn't qualify for whatever Windows
>  marketing programs OEM's get for having certified hardware. That's
>  aside from the fact there's TPM 2.0 in hardware today that the kernel
>  doesn't support and likely won't ever support.
>  
Microsoft is not guaranteeing support or even software updates for
systems that don't have a TPM 2.0 device or otherwise don't meet the
minimum system requirements. So I strongly suspect they'll become the
new standard anyway.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Vitaly Zaitsev]

On 12/12/2021 03:49, Neal Gompa wrote:
>  So I strongly suspect they'll become the
>  new standard anyway. 
TPM is a typical black box. I can't trust it because all hardware TPM 
implementations are proprietary. No one guarantees that it has no backdoors.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; said:
>  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. 
If the admin has done one thing to lock down the system, then they can
do another (removing the sulogin --force addition).  Right now, Fedora
is shipping an inconsistent (and frustrating) state: one part is locked
down, but another is not (so the first can be bypassed, in an annoying
way).  Prompting for a root password at rescue/emergency mode is not
security in the default config and so should not be done (at least when
no such password is set, as some of the default Fedora configs have).

Fedora should ship in a consistent state, and this is the most
straight-forward way of getting there.  Locking down a system beyond the
default requires changing a bunch of things, so I do not see adding this
to that list to be a problem.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 12:03:04PM -0600, Chris Adams wrote:
>  Once upon a time, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl&gt; said:
>  > 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.
>  
>  If the admin has done one thing to lock down the system, then they can
>  do another (removing the sulogin --force addition).  Right now, Fedora
>  is shipping an inconsistent (and frustrating) state: one part is locked
>  down, but another is not (so the first can be bypassed, in an annoying
>  way).  Prompting for a root password at rescue/emergency mode is not
>  security in the default config and so should not be done (at least when
>  no such password is set, as some of the default Fedora configs have). 
I agree that prompting for an unset root password is annoying: we
should just say upfront that the login is not possible that way. But I
don't agree that we should punch an new hole just because a different
one exists. The existing shortcomings are well known, and can be worked
around, and are not relevant in all circumstances. The new mechanism
opens the system from a different side. I also don't think we should
assume that the admin will do a series of "hardening steps". This is what
we had in the 90's: you'd install a stock distro and then go over a checklist
of basic steps to make things secure. Let's not go back to that.

Zbyszek

[Björn Persson]

Chris Adams wrote:
>  If the admin has done one thing to lock down the system, then they
> can
>  do another (removing the sulogin --force addition). 
How do you propose to ensure that the admin is made aware of the need
to do that?

Experienced sysadmins won't just instinctively know that in this new
release of this particular distribution they need to run this special
command to prevent boot problems from granting root access to whoever
can type on the keyboard.

Björn Persson

[Chris Adams]

Once upon a time, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; said:
>  Chris Adams wrote:
>  > If the admin has done one thing to lock down the system, then they can
>  > do another (removing the sulogin --force addition).
>  
>  How do you propose to ensure that the admin is made aware of the need
>  to do that? 
The same way as any change - documentation.

>  Experienced sysadmins won't just instinctively know that in this
> new
>  release of this particular distribution they need to run this special
>  command to prevent boot problems from granting root access to whoever
>  can type on the keyboard. 
It's not a "special command", it's just removing an RPM that has the
sulogin overrides, or just set a root password (this change only affects
the case of a locked root account).  Experienced sysadmins should
already know that the OS changes from release to release.  I don't
install a brand new OS and give it to users without checking it out
myself (and reading at least the release notes).

This is NOT some new "hole" - out of the box, Fedora already allows
someone with console access to get root access (in less convenient, but
more confusing, ways).  As noted in the change proposal, this change is
already in Fedora CoreOS.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Björn Persson]

Chris Adams wrote:
>  Once upon a time, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; said:
>  > Chris Adams wrote:  
>  > > If the admin has done one thing to lock down the system, then they can
>  > > do another (removing the sulogin --force addition).  
>  > 
>  > How do you propose to ensure that the admin is made aware of the need
>  > to do that?  
>  
>  The same way as any change - documentation. 
Introducing a new security hole is not just a change like any other
change.

Sysadmins read documentation to find solutions when they know that they
have a problem to solve. They rarely read documentation to look for
problems they don't know about, and they don't regularly re-read every
document to look for potentially insecure changes.

>  > Experienced sysadmins won't just instinctively know that in
> this new
>  > release of this particular distribution they need to run this special
>  > command to prevent boot problems from granting root access to whoever
>  > can type on the keyboard.  
>  
>  It's not a "special command", it's just removing an RPM 
Po-tay-to, po-tah-to.

>  I don't install a brand new OS and give it to users without
> checking it
>  out myself 
Does "checking it out" include breaking the system in every way you can
think of, to see whether one of them yields a root shell?

>  (and reading at least the release notes). 
Do you also read the release notes of all previous releases just in
case an obscure weakness was introduced in an old release that you
never used, and has been in place since then?

>  This is NOT some new "hole" - out of the box, Fedora
> already allows
>  someone with console access to get root access (in less convenient, but
>  more confusing, ways). 
What you're actually saying is: There is an old hole that we hope
sysadmins are aware of and know how to close if they need to, and
therefore it's fine to punch another hole in a hidden place where
sysadmins won't think to look.

Björn Persson

[Alexander Sosedkin]

On Wed, Dec 8, 2021 at 6:10 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote:
>  Chris Adams wrote:
>  > Once upon a time, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; said:
>  > > Chris Adams wrote:
>  > > > If the admin has done one thing to lock down the system, then they can
>  > > > do another (removing the sulogin --force addition).
>  > >
>  > > How do you propose to ensure that the admin is made aware of the need
>  > > to do that?
>  >
>  > The same way as any change - documentation.
>
>  Introducing a new security hole is not just a change like any other
>  change.
>
>  Sysadmins read documentation to find solutions when they know that they
>  have a problem to solve. They rarely read documentation to look for
>  problems they don't know about, and they don't regularly re-read every
>  document to look for potentially insecure changes.
>
>  > > Experienced sysadmins won't just instinctively know that in this new
>  > > release of this particular distribution they need to run this special
>  > > command to prevent boot problems from granting root access to whoever
>  > > can type on the keyboard.
>  >
>  > It's not a "special command", it's just removing an RPM
>
>  Po-tay-to, po-tah-to.
>
>  > I don't install a brand new OS and give it to users without checking it
>  > out myself
>
>  Does "checking it out" include breaking the system in every way you can
>  think of, to see whether one of them yields a root shell?
>
>  > (and reading at least the release notes).
>
>  Do you also read the release notes of all previous releases just in
>  case an obscure weakness was introduced in an old release that you
>  never used, and has been in place since then?
>
>  > This is NOT some new "hole" - out of the box, Fedora already allows
>  > someone with console access to get root access (in less convenient, but
>  > more confusing, ways).
>
>  What you're actually saying is: There is an old hole that we hope
>  sysadmins are aware of and know how to close if they need to, and
>  therefore it's fine to punch another hole in a hidden place where
>  sysadmins won't think to look. 
Sorry, but this one is a tiny brick at the entrance into
a gigantic dark scary hole called 'physical access',
which usually just trips someone up.

Yes, I can imagine a convoluted specifically constructed scenario
where it can play the pivotal role in the security of the overall system.
Meaning, yes, if you manually build the entire missing wall around it,
yanking it out would be bad for you, sure.
That still doesn't deter me from arguing this is a bad default
worth flipping with all the fanfare we can get about it.

[Chris Adams]

Once upon a time, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; said:
>  Introducing a new security hole is not just a change like any other
>  change. 
Calling this "introducing a new security hole" is hyperbole and
fear-mongering.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Tue, Dec 7, 2021 at 6:28 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
>  > Fedora defaults to locking the root account, which is needed by
>  > single-user mode. This Change uses `sulogin --force` so the password
>  > request is bypassed under this circumstance.
>
>  I think this is a terrible idea. The problem is real, but this
>  solution addresses it in the wrong place. Essentially, you are proposing
>  a behaviour of "something is wrong, let's make everything open without
>  authentication", which is good for debugging and development, but not
>  acceptable for a real system. 
Is it terrible enough that CoreOS should revert?
https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b4539023...


-- 
Chris Murphy

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 08, 2021 at 12:12:33PM -0500, Chris Murphy wrote:
>  On Tue, Dec 7, 2021 at 6:28 AM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  >
>  > On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
>  > > Fedora defaults to locking the root account, which is needed by
>  > > single-user mode. This Change uses `sulogin --force` so the password
>  > > request is bypassed under this circumstance.
>  >
>  > I think this is a terrible idea. The problem is real, but this
>  > solution addresses it in the wrong place. Essentially, you are proposing
>  > a behaviour of "something is wrong, let's make everything open without
>  > authentication", which is good for debugging and development, but not
>  > acceptable for a real system.
>  
>  Is it terrible enough that CoreOS should revert?
>
> https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b4539023...
I'd say that this makes coreos unsuitable as a general purpose image.
Maybe it's OK in limited circumstances where "physical" access is
only possible if you're the administrator on the host.

Zbyszek

[Michel Alexandre Salim]

Hi all,

On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/FixRescueMode
>  
>  == Summary ==
>  Fedora defaults to locking the root account, which is needed by
>  single-user mode. This Change uses `sulogin --force` so the password
>  request is bypassed under this circumstance.
>   
Thanks for all the feedback. Going to do a reply here rather than in
individual subthreads since I'm responding to several suggestions.

For those who thinks this is a security concern (granted, not a new one,
but one that is more convenient), requiring some password seems to be
the way out

- do we want to allow any /local/ %wheel users to log in?
- or do we want to use a recovery passphrase of some sort?
- TPM dependencies might not be appropriate

I'm leaning towards not rushing this and delaying to F37; Chris Murphy
raised a good question on whether the current bypass is fine for CoreOS
or not.

For F36 - I agree that it's better to *not* have a rescue mode than a
broken one. How about this as an end state we can realistically achieve:
- if the root password is set, rescue mode should appear in the GRUB
  menu
- if the root password is not set
  - rescue mode should not be listed
  - if someone tries to invoke it, it should display an error rather
    than prompting for a non-existent password

If that seems reasonable, we can figure out where to put the hooks next.

Best regards,
  
-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]

[Björn Persson]

Michel Alexandre Salim wrote:
>  - do we want to allow any /local/ %wheel users to log in? 
This seems fine to me.

>  - or do we want to use a recovery passphrase of some sort? 
I'm not sure what you mean here. When a passphrase is called a recovery
passphrase, it's usually because authentication is normally done
some other way. For example, if you normally log in by inserting some
kind of hardware token, then you may want a recovery passphrase to use
in case the hardware token is broken or lost.

As long as users normally log in with a passphrase, I see no need to
have a separate passphrase for rescue mode. Root's or a wheel user's
usual passphrase should be fine.

>  For F36 - I agree that it's better to *not* have a rescue mode
> than a
>  broken one. How about this as an end state we can realistically achieve:
>  - if the root password is set, rescue mode should appear in the GRUB
>    menu
>  - if the root password is not set
>    - rescue mode should not be listed
>    - if someone tries to invoke it, it should display an error rather
>      than prompting for a non-existent password 
This looks sane.

If there is a separate boot entry for the rescue mode, then maybe Grub
could be programmed to require a passphrase before it will boot that
entry?

Björn Persson

[Björn Persson]

>  A more user-friendly setup is to allow the password to be bypassed
> in
>  case it's not set.
>  
>  This does not pose an increased security risk:
>  - 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 
To disallow root login in normal operation, and then turn around when a
problem occurs and open a root shell without any login at all, is
inconsistent and will lead users to believe that their computer is more
secure than it actually is.

If Fedora is going to allow unauthenticated root access when there is a
boot problem, then for consistency the same should be true in normal
operation. Both root and other users should by default just be allowed
in without any authentication – not over SSH or any kind of network
access, but on local text consoles and GUI desktops. Anaconda's Root
Account page should be changed to make the root account enabled and
passphraseless by default, and on the User Creation page the checkbox
"Require a password to use this account" should be unchecked by
default. Anyone with physical access to a machine can probably
compromise it, so it's pointless to ask for passphrases on the console,
right?

*That* would be a change that users would be aware of, unlike the one
proposed in the Change proposal – and if users want to enforce the need
for a passphrase, then they can set one, on user accounts as well as on
the root account. When a root passphrase has been set, then that
passphrase should be required in all situations – normal operation,
rescue mode, single-user mode or whatever – and for consistency the
same passphrase should be required in Grub before the boot parameters
can be changed. A user who wants to enforce the need for a passphrase
should be able to do that in one place, not three.

Conversely, if it's considered correct that Anaconda forbids an open
passphraseless root account and promotes setting a passphrase on the
user account, then that policy should be applied consistently, even in
rescue mode. This makes a root passphrase necessary so that rescue mode
can work. Some day it may become possible to use a wheel user's
passphrase in rescue mode. Then, and not before, can the root account
be locked.

In this case, Grub should also by default require root's or a wheel
user's passphrase before boot parameters can be changed. That is
consistent.

Björn Persson