Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Sat, Dec 11, 2021 at 9:43 PM Chris Murphy wrote: > > On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering > wrote: > > > > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 pgp1LnefA7iK9.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
> 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 pgpcT9reGtFmi.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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-network-intrusion-in-30-minutes/ 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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-network-intrusion-in-30-minutes/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Mi, 08.12.21 18:10, Colin Walters (walt...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Mi, 08.12.21 13:28, Chris Murphy (li...@colorremedies.com) wrote: > On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering > wrote: > > > > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 > 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/eb74f2ea3e9b453902315539e4f327481162c4f8 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote: > On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering > wrote: >> >> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Once upon a time, Björn Persson 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering wrote: > > On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Wed, Dec 8, 2021 at 6:10 PM Björn Persson wrote: > > Chris Adams wrote: > > Once upon a time, Björn Persson 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Tue, Dec 7, 2021 at 6:28 AM Zbigniew Jędrzejewski-Szmek 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/eb74f2ea3e9b453902315539e4f327481162c4f8 -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Chris Adams wrote: > Once upon a time, Björn Persson 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 pgpjPAdAJ9zSj.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Once upon a time, Björn Persson 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 pgpUpKi2TnP15.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Tue, Dec 07, 2021 at 12:03:04PM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Once upon a time, Zbigniew Jędrzejewski-Szmek 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Tue, Dec 07, 2021 at 12:01:32PM +, Richard W.M. Jones wrote: > On Tue, Dec 07, 2021 at 11:26:37AM +, 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Tue, Dec 07, 2021 at 11:26:37AM +, 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
Once upon a time, Ben Cotton 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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: mic...@michel-slm.name * Name: [[User:Ngompa|Neal Gompa]] * Email: ngomp...@gmail.com * Name: [[User:Davdunc|David Duncan]] * Email: davd...@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/eb74f2ea3e9b453902315539e4f327481162c4f8 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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
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: mic...@michel-slm.name * Name: [[User:Ngompa|Neal Gompa]] * Email: ngomp...@gmail.com * Name: [[User:Davdunc|David Duncan]] * Email: davd...@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/eb74f2ea3e9b453902315539e4f327481162c4f8 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
