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