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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux