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