Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Thursday, December 5, 2019 12:57:15 AM MST Nicolas Mailhot via devel wrote: > Let’s get real, in most businesses, the data will already be available > in a network share, a common database, etc. Trying to perform fine- > grained control checks on the mass of data businesses routinely > manipulate is a loosing game. You always end up needing to trust > humans. Let's get real. In most business, the data will also be available in a network share. Trying to perform proper separation of permissions is the appropriate method of preventing unauthorized users from gaining that data. You don't need to "trust humans", other than those who do have access to the data. > That’s even the case in ultra-secure environments like the NSA. How do > you think wikileaks happened? No. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Thursday, December 5, 2019 1:03:50 AM MST Nicolas Mailhot via devel wrote: > That works in the GUI. All the low-level parts (including in anaconda > terminal, right after it asked the user to choose a layout) are not > configured properly by the distribution and will fallback to qwerty. That's the case, until you actually install the system with it set globally. That is most likely because the livesystems are built for, I suppose, US QWERTY, and Anaconda devs didn't take switching to vttys into consideration there. > Really, we should try to change the default to Azerty or the Russian > layout for a release. That would teach qwerty users what is hostile to > users of other layouts or not. There is no "default", there is only what the live images are built with. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 8:44:18 PM MST Kevin Kofler wrote: > How would that work? The shell runs on the server. The SSH agent runs on the > client, the only one that has the private key. How can the SSH agent know > that it is talking to your "fake shell" and not to an attacker's fake "fake > shell"? This needs to be part of the protocol, not hacked onto it. The very same way that it already knows when it's talking to `ssh` on a remote server. You've already verified the fingerprint, either manually or using DNS. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Thursday, December 5, 2019 2:56:22 AM MST Lennart Poettering wrote: > Uh, first of all plain full disk encryption like we set it up > typically on Fedora provides confidentiality, not integrity. For the > OS image itself you want integrity though, confidentiality is not > needed (after all anyone can download Fedora from the Internet, > everyone knows all the bits and bytes in it anyway, it's inherently > public information, there's zero point in encrypting it). I have to disagree. The system itself is not just the list of packages installed, but can certainly include software that an individual or company wrote themselves or purchased , and do not wish to lose to a breach. This also includes global configuration files, which may include, for example, a VPN configuration, network configuration and so on. > Unless you combine dm-crypt with dm-integrity (which we currently > generally do not do), or you use dm-verity you are not actually > protecting the OS from undetected modification. Well, you are, in that the average attacker have to break or steal a key to decrypt the drive first. Sure, it wouldn't stop a sophisticated attack. > And there's no point in encrypting /boot, because that contains only > public information too. If you want to protect your boot chain, use > something like a complete SecureBoot chain, but that too is something > we currently don't actually support on Fedora. (because initrds are > not verified). This is not generally true either. Encrypting /boot helps to ensure that /boot is not modified, and is generally paired with GRUB signature validation. In some setups, this GRUB configuration is moved to flash storage. > Anyway, figure out your threat model, and figure out how you want to > protect what, and understand that for different parts of the > installation different rules apply. I don't believe this as the case, as specified above. > And yes, I think encrypting the home directory with the user's own password > makes most sense. I suppose that's a good *start*, where users wouldn't use encryption otherwise. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Hi, Am 05.12.19 um 10:33 schrieb Lennart Poettering: >>> Also note that on Fedora Workstation we default to suspend-on-idle >>> these days. i.e. when you don't actually work on the laptop the laptop >>> is suspended and not reachable via SSH at all, hence adding >>> systemd-homed doesn't make anything worse in that regard... >> How do you wanne access data on your homeserver, when you are at >> work? > Fedora Workstation is — as the name suggests — a workstation OS. It > enforces policies by deault (such as suspend-on-idle) that are not > appropriate for a server. My "workstation" -> is <- my homeserver, or do you have a 19" data rack in your home, just to be able to suspend your "workingstation", when you go to your actual work? No, you don't :) And i don't speculate if you either have a Laptop with all your data on it or a big pc to work with, which is fast & has big storages and good GFX capabilities, because it will be something i did not imagine. So don't assume, you know how people use their stuff, make something universal. IMHO systemd and it's components are there to start a system, not to control it afterwards. That is out of systemds business. > Which has nothing to do with systemd-homed btw, it's the existing > Fedora Workstation behaving that way. Quite right, so why do you wanne take control of it? > Yeah, isn't it great that when you leave your laptop on your desk > unattended you know for sure it's securely locked after a while and > can only be unlocked from you again with your pw? As long as my running system software does not have any major flaws, I already sleep well, if it gets stolen. There are very cool components, most of the users have no knowledge about, that auto lock your system, when you leave the physical area around your laptop. It's already implemented in Fedora today. i.e. via detecting the absence of BT beacons (of any sort) in the near vicinity of the laptop. With FDE running and "Suspend-to-disk" selected in your screensafer settings, you get asked for your password on hw wakeup before your system gets back running. If someone wants to use such things, he already can. Where is the advantage of homed, considering, that only encrypting /home, is a major security flaw by itself. All your goals are already there and it's more useful and secure too :) I really have a problem understanding why you wanne implement a security flaw and call it "better". If you wanne improve security, please focus on userfriendlyneess for things like "disabling unused usb ports"/"whitelist for usb ids"/"insecure Highspeed USB network adapter detection" same for any plugable port you have in your hw. And last, but not least, "motherboard serial number validation on wakeup" to counter the switch of hw components. > I love you too, my friend. Cu :D Best regards, Marius ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Do, 05.12.19 00:40, Marius Schwarz (fedora...@cloud-foo.de) wrote: > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > Anaconda custom partitioning has a per mount point encryption option. > > I can LUKS encrypt only the volume mounted at /home. And if I do this, > If you do this, someone can manipulate your system to trojan horse your > passwords, > when he has physical access to it. > > Full-Diskencryption ( /boot included ) is the only way to protect the > system itself. > Anything else is simply not secure. Uh, first of all plain full disk encryption like we set it up typically on Fedora provides confidentiality, not integrity. For the OS image itself you want integrity though, confidentiality is not needed (after all anyone can download Fedora from the Internet, everyone knows all the bits and bytes in it anyway, it's inherently public information, there's zero point in encrypting it). Unless you combine dm-crypt with dm-integrity (which we currently generally do not do), or you use dm-verity you are not actually protecting the OS from undetected modification. And there's no point in encrypting /boot, because that contains only public information too. If you want to protect your boot chain, use something like a complete SecureBoot chain, but that too is something we currently don't actually support on Fedora. (because initrds are not verified). Anyway, figure out your threat model, and figure out how you want to protect what, and understand that for different parts of the installation different rules apply. And yes, I think encrypting the home directory with the user's own password makes most sense. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Do, 05.12.19 00:21, Marius Schwarz (fedora...@cloud-foo.de) wrote: > Am 03.12.19 um 09:07 schrieb Lennart Poettering: > > Also note that on Fedora Workstation we default to suspend-on-idle > > these days. i.e. when you don't actually work on the laptop the laptop > > is suspended and not reachable via SSH at all, hence adding > > systemd-homed doesn't make anything worse in that regard... > > How do you wanne access data on your homeserver, when you are at > work? Fedora Workstation is — as the name suggests — a workstation OS. It enforces policies by deault (such as suspend-on-idle) that are not appropriate for a server. Which has nothing to do with systemd-homed btw, it's the existing Fedora Workstation behaving that way. > The system will idle, will go into suspend and you can't access it > anymore? Yeah, isn't it great that when you leave your laptop on your desk unattended you know for sure it's securely locked after a while and can only be unlocked from you again with your pw? > I really hope, it's easily configureable, otherwise it will end up here > "dnf erase". I love you too, my friend. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Am 05.12.19 um 01:13 schrieb John M. Harris Jr: >> Full-Diskencryption ( /boot included ) is the only way to protect the >> system itself. >> Anything else is simply not secure. > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > authentication. By all means its security guarantees should be > evaluated. > https://github.com/systemd/systemd/pull/14096 It does not need to, if your system is open to any physical abuser, he simply can exchange the tool to unlock the drive, get the password, send it to the attacker and unlock the drive. Nothing has changed for the user, but it got compromised. And encrypting only parts of your system makes it extrem easy to tamper it. and btw.. nothing stops an attacker from waiting for you to unlock the drive for him, and exfiltrate your data when it's active. System security needs four major anchors to rely on: a full disc encryption a good, not backdoored encryption system secure programs and secure passcodes if you only partly encrypt your disk, your data is only be protected against a random theft and you have to enter your password anyway to unlock it, so you also can encrypt the entire system. There will be no extra work for you to do ;) If you have to worry about someone instantly cooling your RAM down to protect in-memory crypto keys after seizing your laptop, it's time to rethink your lifestyle ;) Best regards, Marius ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Le mercredi 04 décembre 2019 à 17:37 -0700, John M. Harris Jr a écrit : > > > The traditional way is unquestionably hostile to international > > users, > > and doing better, however untraditional, is absolutely something I > > strongly favor. > > How is it "hostile to international users"? "international users" > generally > set their keyboard layout to the one they use primarily.. Just like > everyone else :) That works in the GUI. All the low-level parts (including in anaconda terminal, right after it asked the user to choose a layout) are not configured properly by the distribution and will fallback to qwerty. Really, we should try to change the default to Azerty or the Russian layout for a release. That would teach qwerty users what is hostile to users of other layouts or not. -- Nicolas Mailhot ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Le mercredi 04 décembre 2019 à 16:59 -0700, John M. Harris Jr a écrit : > On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via > devel > wrote: > > - stolen/lost laptop: I think this is the most important one for > > most > > people; it is mitigaged by a trusted-network-based decryption, > > unless > > the device is in unencrypted sleep mode and the new 'beneficial > > owner' > > manages to read the disk before the system goes down. > > That may be the case for home users, but not for businesses. Let's > take this > example. Employee A has files from a given project, but Employee B > doesn't > have access to that project. Employee B is malicious, and takes > Employee A's > laptop, gets it on the network, it unencrypts itself and then takes > it. The > data is not Employee B's. Let’s get real, in most businesses, the data will already be available in a network share, a common database, etc. Trying to perform fine- grained control checks on the mass of data businesses routinely manipulate is a loosing game. You always end up needing to trust humans. That’s even the case in ultra-secure environments like the NSA. How do you think wikileaks happened? -- Nicolas Mailhot ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
John M. Harris Jr wrote: > Oh, of course after fingerprint verification. Luckily, that can be > accomplished by forcing a fake shell which would run a check to see if the > home directory is already mounted. If it's not, it'd use the ssh agent, or > equivalent, then execute the real shell. If it's already mounted, short > circuit to the last step, executing the real shell. How would that work? The shell runs on the server. The SSH agent runs on the client, the only one that has the private key. How can the SSH agent know that it is talking to your "fake shell" and not to an attacker's fake "fake shell"? This needs to be part of the protocol, not hacked onto it. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 6:02:07 PM MST Kevin Kofler wrote: > John M. Harris Jr wrote: > > > Well, you could theoretically use ssh-agent (or equivalent), without > > changing the protocol in any way. > > > You need protocol support to do this securely. Otherwise, your ssh-agent is > a decryption oracle which can be used by an attacker to decrypt your LUKS > keyfile on demand. The decryption should only be possible as part of the > login process after the server fingerprint has been verified and before > arbitrary application data can be sent. Oh, of course after fingerprint verification. Luckily, that can be accomplished by forcing a fake shell which would run a check to see if the home directory is already mounted. If it's not, it'd use the ssh agent, or equivalent, then execute the real shell. If it's already mounted, short circuit to the last step, executing the real shell. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 6:08:31 PM MST Chris Murphy wrote: > On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr > wrote: > > > > > > On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote: > > > > > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr > > > wrote: > > > > > > > > > > > > > > > > > > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anaconda custom partitioning has a per mount point encryption > > > > > > > option. > > > > > > > I can LUKS encrypt only the volume mounted at /home. And if I > > > > > > > do > > > > > > > this, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do this, someone can manipulate your system to trojan > > > > > > horse > > > > > > your > > > > > > passwords, > > > > > > when he has physical access to it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect > > > > > > the > > > > > > system itself. > > > > > > Anything else is simply not secure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > > > > > authentication. By all means its security guarantees should be > > > > > evaluated. > > > > > https://github.com/systemd/systemd/pull/14096 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What you're talking about is entirely up to the user to configure > > > > > manually. Fedora installations today don't support bootloader lock > > > > > down, encrypted /boot, or purging the LUKS key from memory during > > > > > suspend, out of the box. And therefore I'm not sure what your goal > > > > > posts are, what two things you're comparing. > > > > > > > > > > > > > > > > > > > > > > > > It may be the case that the GNOME Spin doesn't support that, but it > > > > is > > > > supported with the KDE Spin. I don't think it's likely that anything > > > > in > > > > the GNOME image would break that, but it's possible I suppose. > > > > > > > > > > > > > > > I have no idea what you mean by "supported" nor which of the multiple > > > characteristics I listed you think apply to Fedora KDE. > > > > > > > > > > > > What I mean by support = that which Fedora produces in release > > > blocking desktops, most typically in a default configuration, and for > > > which release criteria have been written. None of the things I wrote > > > apply to Fedora KDE either, so it's simply not correct to call them > > > supported. The functionality may exist in KDE, but that's not the same > > > thing as what Fedora supports. And I did very clearly write "Fedora > > > installations today don't support..." > > > > > > > > Fedora supports installation on ARM devices with vboot today. > > > The only Fedora KDE image that's release blocking is x86_64. > https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking What does this have to do with "Fedora installations today don't support..."? -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 5:56:39 PM MST Chris Murphy wrote: > On Wed, Dec 4, 2019 at 5:38 PM John M. Harris Jr > wrote: > > > > > > On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote: > > > > > You know what is a work around and not a solution and is default? ~/ > > > isn't encrypted. And the two install time options insist on restricted > > > character sets for the passphrase, the user must not change their > > > keyboard layout, or their keyboard to one with a different keymapping > > > - lest they experience data loss. > > > > > > > > $HOME is encrypted if you put it on an encrypted filesystem > > > You have a particular knack for pointing out the obvious as if you > think everyone is a moron. It's variably amusing and annoying. > > > >Additionally, > > > > that Anaconda restricts what the passphrase for the key sounds like a bug > > in Anaconda. > > > The idea is to protect the user from using characters that can't be > passed via plymouth to cryptsetup during startup. Known problem, I've > only cited it a couple times in this thread. > > > >The user can change their keyboard layout. That's fine. It wouldn't > > > > cause data loss. > > > The user experience is identical to data loss. The passphrase is > considered wrong, there's no feedback whatsoever to the user that the > keymapping has changed, that this is the actual problem. > > https://drive.google.com/open?id=1imiPyYBiTcE3zTsspOhKynWo7ysraRWC > > > > > However, it would make it more difficult to unlock the > > system, if they forget they've changed the keyboard layout and > > regenerated > > their initramfs. (If they do it globally, if they just do it once the OS > > is booted, then they're good to go.) > > > Like I said, it's a user hostile experience. > > > > > > > > The traditional way is unquestionably hostile to international users, > > > and doing better, however untraditional, is absolutely something I > > > strongly favor. > > > > > > > > How is it "hostile to international users"? "international users" > > generally set their keyboard layout to the one they use primarily.. Just > > like everyone else :) > > > Ok so you're not aware of the issues, and you persistently refuse to > go read the issue I've cited multiple times that discuss these > problems, which you previously categorically rejected as even > existing. So it's a stupid or weird game and I refuse to participate. I asked a question because you stated that there is a problem, and what you've described as a problem actually is not one. Please allow me to explain. You can change the keyboard layout, but the original keyboard layout is used unless you rebuild the initramfs afterwards. Simply updating your kernel achieves the same, if you don't know how to do that. The user experience is nothing like data loss. The users are not stupid. It's fine that the keyboard layout for initramfs is only updated when initramfs is rebuilt. People don't change their primary keyboard layout very often. I have to disagree, that this is a "hostile user experience". If you want to fix this, the fix is simple. Rebuild initramfs when the system-wide keyboard layout is changed. Unless something has changed, plymouth does not actually handle input. This may have changed, but was the case as of F29. I don't use Plymouth, so I won't pretend to know what it does in current Fedora. PS: This is not a Fedora requirement, or anything of the sort, but please don't link to proprietary file sharing websites.. It's not really in line with Fedora's Four Foundations, but that's just my opinion. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr wrote: > > On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote: > > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr > > wrote: > > > > > > > > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > > > > > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > > > > > > > > > > > > > > > > > Anaconda custom partitioning has a per mount point encryption > > > > > > option. > > > > > > I can LUKS encrypt only the volume mounted at /home. And if I do > > > > > > this, > > > > > > > > > > > > > > > > > > > > If you do this, someone can manipulate your system to trojan horse > > > > > your > > > > > passwords, > > > > > when he has physical access to it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect the > > > > > system itself. > > > > > Anything else is simply not secure. > > > > > > > > > > > > > > > > > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > > > > authentication. By all means its security guarantees should be > > > > evaluated. > > > > https://github.com/systemd/systemd/pull/14096 > > > > > > > > > > > > > > > > What you're talking about is entirely up to the user to configure > > > > manually. Fedora installations today don't support bootloader lock > > > > down, encrypted /boot, or purging the LUKS key from memory during > > > > suspend, out of the box. And therefore I'm not sure what your goal > > > > posts are, what two things you're comparing. > > > > > > > > > > > > It may be the case that the GNOME Spin doesn't support that, but it is > > > supported with the KDE Spin. I don't think it's likely that anything in > > > the GNOME image would break that, but it's possible I suppose. > > > > > > I have no idea what you mean by "supported" nor which of the multiple > > characteristics I listed you think apply to Fedora KDE. > > > > What I mean by support = that which Fedora produces in release > > blocking desktops, most typically in a default configuration, and for > > which release criteria have been written. None of the things I wrote > > apply to Fedora KDE either, so it's simply not correct to call them > > supported. The functionality may exist in KDE, but that's not the same > > thing as what Fedora supports. And I did very clearly write "Fedora > > installations today don't support..." > > Fedora supports installation on ARM devices with vboot today. The only Fedora KDE image that's release blocking is x86_64. https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
John M. Harris Jr wrote: > Well, you could theoretically use ssh-agent (or equivalent), without > changing the protocol in any way. You need protocol support to do this securely. Otherwise, your ssh-agent is a decryption oracle which can be used by an attacker to decrypt your LUKS keyfile on demand. The decryption should only be possible as part of the login process after the server fingerprint has been verified and before arbitrary application data can be sent. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Chris Murphy wrote: > Fedora installations today don't support bootloader lock down, That can be configured in grub.cfg after installation and it should not break anything. > encrypted /boot, You can actually get that by using Calamares (which is packaged in Fedora) to install Fedora instead of Anaconda. You can even do that on a stock Fedora live image: just open any terminal emulator and run: sudo dnf install calamares kdesu -t calamares (The first command will also install kdesu as a dependency, because it is the best way to run Calamares as root without eating the environment variables needed for desktop integration. So I used kdesu for the second command. This is also what the Calamares menu entry uses, so it is possible to run Calamares from the menu instead if you don't care about the terminal output (that -t flag), which shows some minimal logging by default (use "kdesu -t calamares -d" for more verbose output).) Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 5:38 PM John M. Harris Jr wrote: > > On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote: > > You know what is a work around and not a solution and is default? ~/ > > isn't encrypted. And the two install time options insist on restricted > > character sets for the passphrase, the user must not change their > > keyboard layout, or their keyboard to one with a different keymapping > > - lest they experience data loss. > > $HOME is encrypted if you put it on an encrypted filesystem You have a particular knack for pointing out the obvious as if you think everyone is a moron. It's variably amusing and annoying. >Additionally, > that Anaconda restricts what the passphrase for the key sounds like a bug in > Anaconda. The idea is to protect the user from using characters that can't be passed via plymouth to cryptsetup during startup. Known problem, I've only cited it a couple times in this thread. >The user can change their keyboard layout. That's fine. It wouldn't > cause data loss. The user experience is identical to data loss. The passphrase is considered wrong, there's no feedback whatsoever to the user that the keymapping has changed, that this is the actual problem. https://drive.google.com/open?id=1imiPyYBiTcE3zTsspOhKynWo7ysraRWC > However, it would make it more difficult to unlock the > system, if they forget they've changed the keyboard layout and regenerated > their initramfs. (If they do it globally, if they just do it once the OS is > booted, then they're good to go.) Like I said, it's a user hostile experience. > > > The traditional way is unquestionably hostile to international users, > > and doing better, however untraditional, is absolutely something I > > strongly favor. > > How is it "hostile to international users"? "international users" generally > set their keyboard layout to the one they use primarily.. Just like everyone > else :) Ok so you're not aware of the issues, and you persistently refuse to go read the issue I've cited multiple times that discuss these problems, which you previously categorically rejected as even existing. So it's a stupid or weird game and I refuse to participate. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote: > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr > wrote: > > > > > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > > > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > > > wrote: > > > > > > > > > > > > > > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > > > > > > > > > > > > > Anaconda custom partitioning has a per mount point encryption > > > > > option. > > > > > I can LUKS encrypt only the volume mounted at /home. And if I do > > > > > this, > > > > > > > > > > > > > > > > If you do this, someone can manipulate your system to trojan horse > > > > your > > > > passwords, > > > > when he has physical access to it. > > > > > > > > > > > > > > > > > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect the > > > > system itself. > > > > Anything else is simply not secure. > > > > > > > > > > > > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > > > authentication. By all means its security guarantees should be > > > evaluated. > > > https://github.com/systemd/systemd/pull/14096 > > > > > > > > > > > > What you're talking about is entirely up to the user to configure > > > manually. Fedora installations today don't support bootloader lock > > > down, encrypted /boot, or purging the LUKS key from memory during > > > suspend, out of the box. And therefore I'm not sure what your goal > > > posts are, what two things you're comparing. > > > > > > > > It may be the case that the GNOME Spin doesn't support that, but it is > > supported with the KDE Spin. I don't think it's likely that anything in > > the GNOME image would break that, but it's possible I suppose. > > > I have no idea what you mean by "supported" nor which of the multiple > characteristics I listed you think apply to Fedora KDE. > > What I mean by support = that which Fedora produces in release > blocking desktops, most typically in a default configuration, and for > which release criteria have been written. None of the things I wrote > apply to Fedora KDE either, so it's simply not correct to call them > supported. The functionality may exist in KDE, but that's not the same > thing as what Fedora supports. And I did very clearly write "Fedora > installations today don't support..." Fedora supports installation on ARM devices with vboot today. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr wrote: > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > > wrote: > > > > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > > > Anaconda custom partitioning has a per mount point encryption option. > > > > I can LUKS encrypt only the volume mounted at /home. And if I do this, > > > > > > If you do this, someone can manipulate your system to trojan horse your > > > passwords, > > > when he has physical access to it. > > > > > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect the > > > system itself. > > > Anything else is simply not secure. > > > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > > authentication. By all means its security guarantees should be > > evaluated. > > https://github.com/systemd/systemd/pull/14096 > > > > What you're talking about is entirely up to the user to configure > > manually. Fedora installations today don't support bootloader lock > > down, encrypted /boot, or purging the LUKS key from memory during > > suspend, out of the box. And therefore I'm not sure what your goal > > posts are, what two things you're comparing. > > It may be the case that the GNOME Spin doesn't support that, but it is > supported with the KDE Spin. I don't think it's likely that anything in the > GNOME image would break that, but it's possible I suppose. I have no idea what you mean by "supported" nor which of the multiple characteristics I listed you think apply to Fedora KDE. What I mean by support = that which Fedora produces in release blocking desktops, most typically in a default configuration, and for which release criteria have been written. None of the things I wrote apply to Fedora KDE either, so it's simply not correct to call them supported. The functionality may exist in KDE, but that's not the same thing as what Fedora supports. And I did very clearly write "Fedora installations today don't 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 5:28:17 PM MST Chris Murphy wrote: > You know what is a work around and not a solution and is default? ~/ > isn't encrypted. And the two install time options insist on restricted > character sets for the passphrase, the user must not change their > keyboard layout, or their keyboard to one with a different keymapping > - lest they experience data loss. $HOME is encrypted if you put it on an encrypted filesystem. Additionally, that Anaconda restricts what the passphrase for the key sounds like a bug in Anaconda. The user can change their keyboard layout. That's fine. It wouldn't cause data loss. However, it would make it more difficult to unlock the system, if they forget they've changed the keyboard layout and regenerated their initramfs. (If they do it globally, if they just do it once the OS is booted, then they're good to go.) > The traditional way is unquestionably hostile to international users, > and doing better, however untraditional, is absolutely something I > strongly favor. How is it "hostile to international users"? "international users" generally set their keyboard layout to the one they use primarily.. Just like everyone else :) -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 4:59 PM John M. Harris Jr wrote: > > On Wednesday, December 4, 2019 12:00:06 PM MST Chris Murphy wrote: > > Other alternatives: > > a. At least on ext4, you can today selectively encrypt directories and > > files, so you could have an non-encrypted ~/ by default, and choose > > what directories to encrypt. There's no GUI assistance for this yet > > that I'm aware of. > > b. If you can clearly compartmentalize our use cases, you can have two > > accounts, one is encrypted and other not. > > > > I think the later two put a lot of burden on the user to figure out > > and manage. I'm not sure there's a way for GNOME or systemd-homed to > > directly support such use cases, but I also don't expect it would > > stand in the way of user implementation of such a scheme. > > "Alternative" B is a complete cop-out. It's essentially ignoring the fault > entirely, and blaming the using for wanting to do something the traditional > way. > > That is a workaround, not a solution. It's a fair criticism, but it's also not a solution I'm advocating as a default behavior either. You know what is a work around and not a solution and is default? ~/ isn't encrypted. And the two install time options insist on restricted character sets for the passphrase, the user must not change their keyboard layout, or their keyboard to one with a different keymapping - lest they experience data loss. The traditional way is unquestionably hostile to international users, and doing better, however untraditional, is absolutely something I strongly favor. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > wrote: > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > Anaconda custom partitioning has a per mount point encryption option. > > > I can LUKS encrypt only the volume mounted at /home. And if I do this, > > > > If you do this, someone can manipulate your system to trojan horse your > > passwords, > > when he has physical access to it. > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect the > > system itself. > > Anything else is simply not secure. > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > authentication. By all means its security guarantees should be > evaluated. > https://github.com/systemd/systemd/pull/14096 > > What you're talking about is entirely up to the user to configure > manually. Fedora installations today don't support bootloader lock > down, encrypted /boot, or purging the LUKS key from memory during > suspend, out of the box. And therefore I'm not sure what your goal > posts are, what two things you're comparing. It may be the case that the GNOME Spin doesn't support that, but it is supported with the KDE Spin. I don't think it's likely that anything in the GNOME image would break that, but it's possible I suppose. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz wrote: > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > Anaconda custom partitioning has a per mount point encryption option. > > I can LUKS encrypt only the volume mounted at /home. And if I do this, > If you do this, someone can manipulate your system to trojan horse your > passwords, > when he has physical access to it. > > Full-Diskencryption ( /boot included ) is the only way to protect the > system itself. > Anything else is simply not secure. systemd-homed doesn't depend on /etc/passwd or /etc/shadow for authentication. By all means its security guarantees should be evaluated. https://github.com/systemd/systemd/pull/14096 What you're talking about is entirely up to the user to configure manually. Fedora installations today don't support bootloader lock down, encrypted /boot, or purging the LUKS key from memory during suspend, out of the box. And therefore I'm not sure what your goal posts are, what two things you're comparing. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel wrote: > - stolen/lost laptop: I think this is the most important one for most > people; it is mitigaged by a trusted-network-based decryption, unless > the device is in unencrypted sleep mode and the new 'beneficial owner' > manages to read the disk before the system goes down. That may be the case for home users, but not for businesses. Let's take this example. Employee A has files from a given project, but Employee B doesn't have access to that project. Employee B is malicious, and takes Employee A's laptop, gets it on the network, it unencrypts itself and then takes it. The data is not Employee B's. > - someone breaks into your home/office/hotel room and extracts the data: > important to some people but not very common scenario. This is important to most businesses. > You are correct that it's hard to mitigate both of those threats, but I > think the first one is the primary concern. > > To be clear, I was suggesting a network scheme where your device > authenticates from e.g. a trusted subnet to a known server IP with a > specific certificate associated with this IP. To defeat this, you can't > just set up a a fake IP network ---you would have to somehow break into > (physically or at least electronically) the trusted subnet. Right, of course. The only method for network based decryption that I am aware of is a server that you must set up. I don't think a > By the way, as I said. Android/IOS solved those issues by having a > secure boot process, There's nothing inherently "secure" about Android's boot process, though I'm not familiar with that of iOS. Depending on the version, and this is different in the most popular fork, a key is either immediately requested to decrypt the system or the system itself is unencrypted to begin with, and key is requested to decrypt user data. > so the OS can fully boot and will keep the secrets > until local ( or possibly remote) authentication. See above. > So this is a solved problem, and perhaps we should be looking into securing > the full boot process instead of trying to mitigate threats resulting from > the holes in it. Well, it really isn't a "solved problem". Most of these "secure boot" solutions don't actually do anything that makes them inherently secure, vboot included. They're just trusting a vendor key, by default. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 4:40:14 PM MST Marius Schwarz wrote: > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > Anaconda custom partitioning has a per mount point encryption option. > > I can LUKS encrypt only the volume mounted at /home. And if I do this, > > If you do this, someone can manipulate your system to trojan horse your > passwords, > when he has physical access to it. > > Full-Diskencryption ( /boot included ) is the only way to protect the > system itself. > Anything else is simply not secure. > > best regards, > Marius Agreed. One of the most common solutions to this is coreboot with a GRUB payload. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 4:22 PM Marius Schwarz wrote: > > Am 03.12.19 um 09:07 schrieb Lennart Poettering: > > Also note that on Fedora Workstation we default to suspend-on-idle > > these days. i.e. when you don't actually work on the laptop the laptop > > is suspended and not reachable via SSH at all, hence adding > > systemd-homed doesn't make anything worse in that regard... > > > > How do you wanne access data on your homeserver, when you are at work? And how do you want to protect it, when you're at work? > > The system will idle, will go into suspend and you can't access it anymore? You do understand that present day suspend to RAM, the encryption keys are in memory and your data is not protected at rest? Locking ~/ prior to suspend is a feature. It's intentional that you can't access ~/ until you authenticate again. The challenge is how to make remote authentication that does both login and ~/ unlock possible. > > I really hope, it's easily configureable, otherwise it will end up here > "dnf erase". The challenge will be how to convey the configuration, and its different consequences to the user. And it's not even decided what the default behaviors would be. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 12:00:06 PM MST Chris Murphy wrote: > Other alternatives: > a. At least on ext4, you can today selectively encrypt directories and > files, so you could have an non-encrypted ~/ by default, and choose > what directories to encrypt. There's no GUI assistance for this yet > that I'm aware of. > b. If you can clearly compartmentalize our use cases, you can have two > accounts, one is encrypted and other not. > > I think the later two put a lot of burden on the user to figure out > and manage. I'm not sure there's a way for GNOME or systemd-homed to > directly support such use cases, but I also don't expect it would > stand in the way of user implementation of such a scheme. "Alternative" B is a complete cop-out. It's essentially ignoring the fault entirely, and blaming the using for wanting to do something the traditional way. That is a workaround, not a solution. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Am 04.12.19 um 02:02 schrieb Chris Murphy: > Anaconda custom partitioning has a per mount point encryption option. > I can LUKS encrypt only the volume mounted at /home. And if I do this, If you do this, someone can manipulate your system to trojan horse your passwords, when he has physical access to it. Full-Diskencryption ( /boot included ) is the only way to protect the system itself. Anything else is simply not secure. best regards, Marius ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Am 03.12.19 um 09:07 schrieb Lennart Poettering: > Also note that on Fedora Workstation we default to suspend-on-idle > these days. i.e. when you don't actually work on the laptop the laptop > is suspended and not reachable via SSH at all, hence adding > systemd-homed doesn't make anything worse in that regard... > How do you wanne access data on your homeserver, when you are at work? The system will idle, will go into suspend and you can't access it anymore? I really hope, it's easily configureable, otherwise it will end up here "dnf erase". best regards, Marius ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 12/4/19 5:25 AM, John M. Harris Jr wrote: Network based decryption keys are possible, but I don't recommend it, because there's no way to determine that the user booting up the system is actually meant to have access to the data that's on it. There are two distinct thread models : - stolen/lost laptop: I think this is the most important one for most people; it is mitigaged by a trusted-network-based decryption, unless the device is in unencrypted sleep mode and the new 'beneficial owner' manages to read the disk before the system goes down. - someone breaks into your home/office/hotel room and extracts the data: important to some people but not very common scenario. You are correct that it's hard to mitigate both of those threats, but I think the first one is the primary concern. To be clear, I was suggesting a network scheme where your device authenticates from e.g. a trusted subnet to a known server IP with a specific certificate associated with this IP. To defeat this, you can't just set up a a fake IP network ---you would have to somehow break into (physically or at least electronically) the trusted subnet. By the way, as I said. Android/IOS solved those issues by having a secure boot process, so the OS can fully boot and will keep the secrets until local ( or possibly remote) authentication. So this is a solved problem, and perhaps we should be looking into securing the full boot process instead of trying to mitigate threats resulting from the holes in 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wed, Dec 4, 2019 at 9:01 AM Roberto Ragusa wrote: > > On 12/4/19 12:28 AM, Chris Murphy wrote: > > > I actually prefer the idea that'd if I'm not logged in, my data is > > considered at rest and crypto home is locked, in contrast to how FDE > > does it which treats my data as not at rest even though I'm not logged > > in at all. > > On the other hand I would expect my cronjobs to be able to run "as me" > even if I'm not physically present. > This "logged in" concept coming from Windows and OS X never fits too well > with Linux. It's a valid use case that is being taken into account. The open question is the degree of "lock down" by default. You'd still be able to opt out of login being tied to ~/ encryption, if that is incongruent with your workflow. And you'd still be able to opt into a conventional full disk encryption scheme instead. Other alternatives: a. At least on ext4, you can today selectively encrypt directories and files, so you could have an non-encrypted ~/ by default, and choose what directories to encrypt. There's no GUI assistance for this yet that I'm aware of. b. If you can clearly compartmentalize our use cases, you can have two accounts, one is encrypted and other not. I think the later two put a lot of burden on the user to figure out and manage. I'm not sure there's a way for GNOME or systemd-homed to directly support such use cases, but I also don't expect it would stand in the way of user implementation of such a scheme. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 12/4/19 12:28 AM, Chris Murphy wrote: I actually prefer the idea that'd if I'm not logged in, my data is considered at rest and crypto home is locked, in contrast to how FDE does it which treats my data as not at rest even though I'm not logged in at all. On the other hand I would expect my cronjobs to be able to run "as me" even if I'm not physically present. This "logged in" concept coming from Windows and OS X never fits too well with Linux. Regards. -- Roberto Ragusamail at robertoragusa.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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Wednesday, December 4, 2019 3:53:08 AM MST Lennart Poettering wrote: > To my knowledge the SSH protocol doesn't have provisions for allowing > that. i.e. there's no API and no protocol for allowing apps on the > server to ask for decryption of arbitrary blobs from the client. > > I mean, I am happy to support anything that we can do, but I am not > sure I want to get involved with SSH enough to amend protocol and > implementation for this, given that I don't even think it's as crucial > as some people think it is... Well, you could theoretically use ssh-agent (or equivalent), without changing the protocol in any way. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Di, 03.12.19 16:28, Chris Murphy (li...@colorremedies.com) wrote: > Trying to get back on track with this thread though, if systemd-homed > is available by the time startup reaches rescue.target, does this > somewhat confuse the distinction of whatever multi-user.target is, > which would then rather be more like manyservices.target in contrast > to fewservices.target? I also don't know if systemd-homed is simple > enough that it's a good idea to make it available by rescue.target. > But then, also what about emergency.target which is even more > rudimentary and likewise requires root? The only thing stopping systemd-homed to run in early boot is D-Bus: communication with systemd-homed is mostly D-Bus and that is run after basic.target, hence logging earlier into home directories managed by homed is not doable (at least how things are right now). 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mi, 04.12.19 03:12, John M. Harris Jr (joh...@splentity.com) wrote: > I don't see how redefining "at rest" is useful here. Especially because, I > can't imagine a time where my user isn't logged in in one way or another, or a > user that has permissions to enter my home directory is logged in. Further, > when one of their cron jobs run, or a systemd user service runs, would that > use a cached key to unlock their home directory? in systemd-homed cronjobs can't run as long as you aren't logged in. If you are logged in all is good and they run as they traditionally did, but if you aren't logged in then the LUKS volume is locked and there's no password available from cron we could use to unlock the volume. It's a feature not a bug though: systemd-homed gives you much stronger security guarantees: as long as you are present on the device the device has can access the data on behalf of you. But as soon as you leave (by logging out or suspending the machine) the data as locked and the keys removed from memory so that access is logically impossible. (One thinkable extension of homed's current model btw is to support logind lingering by asking for the user pw using plymouth. this would then mean you'd be asked to unlock your user during early boot like as with classic disk encryption, and then it remains unlocked for the entire lifetime of the system. But I am not sure it's worth it, if you are happy with such a much weaker model you might as well use regular full disk encryption and have the home dirs themselves just be plain directories) 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mi, 04.12.19 03:09, Kevin Kofler (kevin.kof...@chello.at) wrote: > Lennart Poettering wrote: > > The problem is that sshd's PAM implementation doesn't allow PAM > > modules to ask questions in login sessions which are authenticated via > > authorized_keys instead of PAM. Because if we could ask questions > > then, we could simply ask the user for the passphrase to derive the > > LUKS key from if we need. That would mean that if you SSH login if you > > already are logged in locally, then logins would be instant, but if > > you SSH login otherwise then you'd get a prompt for the pw first. > > I think a proper SSH integration would actually store a LUKS keyfile > encrypted with the SSH public key somewhere in .ssh, and on login, send that > to the client, have that decrypt it with the SSH private key and send it > back, and use the decrypted key to unlock the LUKS partition. To my knowledge the SSH protocol doesn't have provisions for allowing that. i.e. there's no API and no protocol for allowing apps on the server to ask for decryption of arbitrary blobs from the client. I mean, I am happy to support anything that we can do, but I am not sure I want to get involved with SSH enough to amend protocol and implementation for this, given that I don't even think it's as crucial as some people think it is... 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, December 3, 2019 12:35:01 PM MST Przemek Klosowski via devel wrote: > I think Chris is referring to the fact that you have to be there when > the encrypted system is restarted, to type the decryption key/password. > The dilemma is this: if the decryption is automatic, it doesn't really > protect the data at rest, because the boot process is not secured like > it is on Android or IOS, and therefore the intruders could get in and > access the now-unencrypted disk. > > It is conceivable to set up some sort of location-based decryption, > where you would not have to give the password if the system is on a > known network, authenticating through a trusted interface to a known > host, but it's not a solved problem. There are solutions for this, in the form of dracut modules that spawn an SSH server, and wait for you to connect and unlock the system, if you are not available to unlock it physically. Network based decryption keys are possible, but I don't recommend it, because there's no way to determine that the user booting up the system is actually meant to have access to the data that's on it. However, if you're interested in network based keys for that purpose, that'd be a surprisingly simple project. I believe there was a blog post from a Red Hat engineer a few years ago about network based luks volume decryption. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, December 3, 2019 6:57:37 PM MST Kevin Kofler wrote: > This depends (even in the absence of disk encryption) on where you have told > plasma-nm to store your WPA (or 802.11x etc.) credentials (unless you are > using an entirely open network). (The credential storage strategy is > configurable in plasma-nm.) Of course, that would be for wireless systems, or systems with 802.1X not using host certificates. For my own setup, this is not an issue, because I use FreeIPA provisioning certificates for WPA2 EAP-TLS for wireless and 802.1X EAP-TLS for wired clients. I can definitely see how that would apply to most wireless users though. I definitely overlooked ssh'ing into systems that are primarily wireless. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, December 3, 2019 6:02:57 PM MST Chris Murphy wrote: > sshd doesn't startup until after this. You can't ssh into your system > before user home is unlocked. There is at least a chance of this with > systemd-homed even if it's not yet implemented. For the record, it is not unheard of for LUKS encrypted systems to use something like dracut-crypt-ssh or dracut-sshd in order to unlock their system during initramfs. > That's because you are physically present to type in a passphrase > during boot. And that exposes all user data as plaintext too, in the > FDE case. The only thing protecting user data are discretionary access > controls. How does that "expose[] all user data as plaintext"? > The reason for a full desktop environment stack being available at > LUKS unlock time has to do with various UX problems with the much more > limited initramfs+plymouth environment. This is elaborated on in the > Workstation WG issue I referenced. An open question is to what degree > we run into those same kinds of problems with remote login. I would have to disagree with that, but I don't have a dog in that fight for GNOME anyway. > It's a valid argument that when a user is not logged in, their data > should be at rest and encrypted. systemd-homed is one possible way to > address that, not necessarily the only way, but for sure the current > options in the installer don't address it. I don't see how redefining "at rest" is useful here. Especially because, I can't imagine a time where my user isn't logged in in one way or another, or a user that has permissions to enter my home directory is logged in. Further, when one of their cron jobs run, or a systemd user service runs, would that use a cached key to unlock their home directory? While some users might not be logged in constantly (either graphically, via SSH, a virtual terminal, screen/tmux session or whatever), it is much more common for users to have cron jobs or user units set up. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Lennart Poettering wrote: > The problem is that sshd's PAM implementation doesn't allow PAM > modules to ask questions in login sessions which are authenticated via > authorized_keys instead of PAM. Because if we could ask questions > then, we could simply ask the user for the passphrase to derive the > LUKS key from if we need. That would mean that if you SSH login if you > already are logged in locally, then logins would be instant, but if > you SSH login otherwise then you'd get a prompt for the pw first. I think a proper SSH integration would actually store a LUKS keyfile encrypted with the SSH public key somewhere in .ssh, and on login, send that to the client, have that decrypt it with the SSH private key and send it back, and use the decrypted key to unlock the LUKS partition. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
John M. Harris Jr wrote: > however with Plasma, my desktop environment doesn't have to be loaded at > all in order for me to ssh in. This depends (even in the absence of disk encryption) on where you have told plasma-nm to store your WPA (or 802.11x etc.) credentials (unless you are using an entirely open network). (The credential storage strategy is configurable in plasma-nm.) If the credentials are stored in system-wide unencrypted storage, you can SSH in immediately. If they are stored in your KWallet, you have to log in first so that plasma-nm knows what wallet to unlock, and if you use the default setup, so that the KWallet PAM module can use your login password to unlock your wallet. (You can also have an entirely passwordless KWallet, but even that would not help you in this case because NM would still not know where to look for your credentials. You need to have plasma-nm running, and as the correct user, to get working KWallet NM integration.) And if you use a non-empty KWallet password that is not your login password, you also have to enter that, of course. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Dec 3, 2019 at 12:05 AM John M. Harris Jr wrote: > > > It's not just an issue for systemd-homed, this problem applies to any > > user home encryption implementation when the user has not first > > authenticated/unlocked their user home. e.g. if you install with /home > > encrypted in Anaconda, in fact your boot stops at plymouth in the > > initramfs so sshd is thwarted from even starting in the first place; > > and even if GNOME Shell's login were to be enhanced to do this unlock, > > still requires unlock. > > That is simply not the case. I don't know what you're referring to with "if > you install with /home encrypted in Anaconda", Anaconda custom partitioning has a per mount point encryption option. I can LUKS encrypt only the volume mounted at /home. And if I do this, startup is inhibited at a plymouth prompt for a passphrase, the same as if I check the earlier "encrypt my data" option at Destination Installation - which is the FDE layout. sshd doesn't startup until after this. You can't ssh into your system before user home is unlocked. There is at least a chance of this with systemd-homed even if it's not yet implemented. >or why GNOME Shell would have > anything to ssh, however with Plasma, my desktop environment doesn't have to > be loaded at all in order for me to ssh in. That's because you are physically present to type in a passphrase during boot. And that exposes all user data as plaintext too, in the FDE case. The only thing protecting user data are discretionary access controls. The reason for a full desktop environment stack being available at LUKS unlock time has to do with various UX problems with the much more limited initramfs+plymouth environment. This is elaborated on in the Workstation WG issue I referenced. An open question is to what degree we run into those same kinds of problems with remote login. > > > Basically you have to choose between user home security (or more > > specifically privacy) and remote logins. However, there are some ideas > > that could possibly work around this, to varying degrees of > > inelegance, which I'll gratuitously copy from a related Workstation WG > > issue [1]. > > You really don't. It's pretty much there by default, and there's not a lot > that I have to change from a default Plasma install. Doing an Anaconda guided > LVM full disk encryption setup is sufficient to protect data at rest. It's a valid argument that when a user is not logged in, their data should be at rest and encrypted. systemd-homed is one possible way to address that, not necessarily the only way, but for sure the current options in the installer don't address it. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 2, 2019 at 11:58 PM John M. Harris Jr wrote: > > On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote: > > It's almost 2020, and I shouldn't have to pick and choose between > > remote access and securing user data at rest by default. > > You don't have to. Data at rest would mean that your system is powered off, or > suspended to disk. You can have that now with full disk encryption, just as I > do. Depending on your system, you can actually encrypt the entire disk such > that you don't even have a partition table. I do this with my X200 Tablet, > where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS > mountpoints, swaps on a ZFS zdev. OK you just took a 90 degree turn, detouring the line of discussion, which was your premise that systemd-homed is pointless if the user can't ssh into it. There is no difference between a systemd-homed encrypted user home, and FDE, in this respect. Someone must type in a passphrase to unlock the volume that contains the user home you want access to it with ssh, in both cases. In your case you have to physically type that passphrase when you startup, at plymouth. In the systemd-homed case, login and crypto home unlock are tied together. I actually prefer the idea that'd if I'm not logged in, my data is considered at rest and crypto home is locked, in contrast to how FDE does it which treats my data as not at rest even though I'm not logged in at all. Trying to get back on track with this thread though, if systemd-homed is available by the time startup reaches rescue.target, does this somewhat confuse the distinction of whatever multi-user.target is, which would then rather be more like manyservices.target in contrast to fewservices.target? I also don't know if systemd-homed is simple enough that it's a good idea to make it available by rescue.target. But then, also what about emergency.target which is even more rudimentary and likewise requires root? systemd.debug-shell=1 does provide a root shell on tty9, by the time rescue.target is reached. And in that shell I can extract rdsosreport.txt or a full journal among other things, and get running again. It's admittedly obscure knowledge though. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 12/3/19 1:57 AM, John M. Harris Jr wrote: On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote: It's almost 2020, and I shouldn't have to pick and choose between remote access and securing user data at rest by default. You don't have to. Data at rest would mean that your system is powered off, or suspended to disk. You can have that now with full disk encryption, just as I do. Depending on your system, you can actually encrypt the entire disk such that you don't even have a partition table. I do this with my X200 Tablet, where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS mountpoints, swaps on a ZFS zdev. I think Chris is referring to the fact that you have to be there when the encrypted system is restarted, to type the decryption key/password. The dilemma is this: if the decryption is automatic, it doesn't really protect the data at rest, because the boot process is not secured like it is on Android or IOS, and therefore the intruders could get in and access the now-unencrypted disk. It is conceivable to set up some sort of location-based decryption, where you would not have to give the password if the system is on a known network, authenticating through a trusted interface to a known host, but it's not a solved problem. ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Dec 3, 2019 at 9:07 am, Lennart Poettering wrote: Also note that on Fedora Workstation we default to suspend-on-idle these days. i.e. when you don't actually work on the laptop the laptop is suspended and not reachable via SSH at all, hence adding systemd-homed doesn't make anything worse in that regard... Hi, A clarification. This is true upstream, but in Fedora it is only true for laptops on battery power. Desktops and laptops that are plugged in do not suspend on idle (unless you have changed the settings from our defaults). It would be unusual to SSH into a laptop on battery power unless you are physically present in the room (since it could run out of power). Michael ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Di, 03.12.19 01:29, John M. Harris Jr (joh...@splentity.com) wrote: > > The problem is that sshd's PAM implementation doesn't allow PAM > > modules to ask questions in login sessions which are authenticated via > > authorized_keys instead of PAM. Because if we could ask questions > > then, we could simply ask the user for the passphrase to derive the > > LUKS key from if we need. That would mean that if you SSH login if you > > already are logged in locally, then logins would be instant, but if > > you SSH login otherwise then you'd get a prompt for the pw first. > > Is the key's passphrase always going to be based on the user's password with > systed-homed? Is there a mechanism to use a separate password? In theory the infrastructure would allow that, but systemd-homed's idea is really to unify authentication, and make disk encryption part of the user account an implementation detail. Hence, in systemd-homed you can have N passwords and M PKCS#11 tokens (i.e. yubikeys) and these translate to N+M keyslots on the LUKS volume, so that any supplied password or any supplied yubikey unlocks the whole stack. (And N and M can individually be zero, but N+M must be > 0) (And systemd-homed also supports ext4 encryption as backend, as well as unencrypted backends, and authentication works the same there except that the keys are never propagated to any storage backend because the storage backend has no interest in cryptographic key material) 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, December 3, 2019 1:18:57 AM MST Lennart Poettering wrote: > systemd-homed integrates with sshd's AuthorizedKeysCommand and > supplies any SSH keys assoicated with the user account directly to SSH > without anyone needing access ~/.ssh/. i.e. integration with SSH is > actually already in place. Excellent, that's what I mentioned in the other subthread. Does this use sssd's existing AuthorizedKeysCommand, or would it interfere with it? > The problem is that sshd's PAM implementation doesn't allow PAM > modules to ask questions in login sessions which are authenticated via > authorized_keys instead of PAM. Because if we could ask questions > then, we could simply ask the user for the passphrase to derive the > LUKS key from if we need. That would mean that if you SSH login if you > already are logged in locally, then logins would be instant, but if > you SSH login otherwise then you'd get a prompt for the pw first. Is the key's passphrase always going to be based on the user's password with systed-homed? Is there a mechanism to use a separate password? -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mo, 02.12.19 12:39, Chris Murphy (li...@colorremedies.com) wrote: > Basically you have to choose between user home security (or more > specifically privacy) and remote logins. However, there are some > ideas that could possibly work around this, to varying degrees of > inelegance, which I'll gratuitously copy from a related Workstation > WG issue [1]. > > 1. Enhance openssh's PAM support > 2. Stub account to ssh into, whereby the user is prompted to > authenticate+unlock the real account; and now ssh into the real > account. > 3. Same as 2 but maybe it's possible to bind mount the real home dir > over the stub home dir, eliminating the 2nd login? (Vaguely recall > reading about this somewhere, maybe Ubuntu's use of ecryptfs based > home, now since deprecated in favor of LUKS) > 4. If based on any fscrypt implementation, exclude ~/.ssh/ from > encryption systemd-homed integrates with sshd's AuthorizedKeysCommand and supplies any SSH keys assoicated with the user account directly to SSH without anyone needing access ~/.ssh/. i.e. integration with SSH is actually already in place. The problem is that sshd's PAM implementation doesn't allow PAM modules to ask questions in login sessions which are authenticated via authorized_keys instead of PAM. Because if we could ask questions then, we could simply ask the user for the passphrase to derive the LUKS key from if we need. That would mean that if you SSH login if you already are logged in locally, then logins would be instant, but if you SSH login otherwise then you'd get a prompt for the pw first. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mo, 02.12.19 10:44, John M. Harris Jr (joh...@splentity.com) wrote: > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote: > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > >> Mabee systemd-homed is in > > >> a position to solve this by having early enough authentication > > >> capability by rescue.target time that any admin user can login? > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > > implemented together with changes to how user metadata querying is done: > > > instead of using dbus, a brokerless and much simpler varlink query is > > > used. > > > That last part is what would be relevant to early-boot logins, because > > > less services need to be up to bring up the user session. > > > > There's one tricky feature of homed : remote login (ssh) is only > > possible after an initial local login. It is OK for his intended use (a > > personal laptop/tablet client), except for corner cases like a remotely > > accessed personal desktop in the basement that might get rebooted e.g. > > for updates, resulting in an accidental lockout. > > Basically, systemd-homed is useless for any power user, but might be useful > for people just getting into GNU/Linux, who don't use ssh yet or don't have > more than one system. You can SSH into a systemd-homed account just fine, you just need to unlock the home directory once first, for example by logging in locally. The key to unlock the home directory needs to come from somewhere, hence a PAM authentication has to take place once, so that systemd-homed can derive the LUKS key once from the pw you enter. However, if you never authenticated via PAM (but via ssh authorized keys only) then there's no pw to unlock the volume with. It's exactly the same as with LUKS encrypted traditional /home or root btw, except that the unlocking is moved a bit later: i.e. things are just much worse there, because you have to enter the pw at boot already and thus your secrets are already unlocked when you haven't even logged in. Also note that on Fedora Workstation we default to suspend-on-idle these days. i.e. when you don't actually work on the laptop the laptop is suspended and not reachable via SSH at all, hence adding systemd-homed doesn't make anything worse in that regard... 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, December 2, 2019 12:39:52 PM MST Chris Murphy wrote: > On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel > wrote: > > > > > > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > > > > > > > Mabee systemd-homed is in > > a position to solve this by having early enough authentication > > capability by rescue.target time that any admin user can login? > > > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > implemented together with changes to how user metadata querying is done: > > instead of using dbus, a brokerless and much simpler varlink query is > > used. That last part is what would be relevant to early-boot logins, > > because less services need to be up to bring up the user session. > > > > > > > > There's one tricky feature of homed : remote login (ssh) is only possible > > after an initial local login. It is OK for his intended use (a personal > > laptop/tablet client), except for corner cases like a remotely accessed > > personal desktop in the basement that might get rebooted e.g. for > > updates, resulting in an accidental lockout. > > It's not just an issue for systemd-homed, this problem applies to any > user home encryption implementation when the user has not first > authenticated/unlocked their user home. e.g. if you install with /home > encrypted in Anaconda, in fact your boot stops at plymouth in the > initramfs so sshd is thwarted from even starting in the first place; > and even if GNOME Shell's login were to be enhanced to do this unlock, > still requires unlock. That is simply not the case. I don't know what you're referring to with "if you install with /home encrypted in Anaconda", or why GNOME Shell would have anything to ssh, however with Plasma, my desktop environment doesn't have to be loaded at all in order for me to ssh in. > Basically you have to choose between user home security (or more > specifically privacy) and remote logins. However, there are some ideas > that could possibly work around this, to varying degrees of > inelegance, which I'll gratuitously copy from a related Workstation WG > issue [1]. You really don't. It's pretty much there by default, and there's not a lot that I have to change from a default Plasma install. Doing an Anaconda guided LVM full disk encryption setup is sufficient to protect data at rest. > 1. Enhance openssh's PAM support What do you believe needs to be "enhanced"? > 2. Stub account to ssh into, whereby the user is prompted to > authenticate+unlock the real account; and now ssh into the real > account. Why should somebody have to create TWO accounts in order to access their system? > 3. Same as 2 but maybe it's possible to bind mount the real home dir > over the stub home dir, eliminating the 2nd login? (Vaguely recall > reading about this somewhere, maybe Ubuntu's use of ecryptfs based > home, now since deprecated in favor of LUKS) If we really wanted to, that's possible now, without systemd-homed. > 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption That's a bad idea. That directory, by default, contains ssh private keys, as well as the list of authorized keys. A better workaround would be similar to what is already implemented for sssd, where a proxy command is used to get the authorized keys for an account. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote: > It's almost 2020, and I shouldn't have to pick and choose between > remote access and securing user data at rest by default. You don't have to. Data at rest would mean that your system is powered off, or suspended to disk. You can have that now with full disk encryption, just as I do. Depending on your system, you can actually encrypt the entire disk such that you don't even have a partition table. I do this with my X200 Tablet, where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS mountpoints, swaps on a ZFS zdev. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, December 2, 2019 11:16:43 AM MST Zbigniew Jędrzejewski-Szmek wrote: > How often do you ssh *into* your laptop? Every time I'm on another system without access to my NFS server, or I need my GnuPG key when not using my laptop. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 2, 2019 at 12:39 PM Chris Murphy wrote: > 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption Actually this is essentially the same problem. Yes, I've ssh'd into the real home, but everything is still encrypted, so I'd have to unlock my home dir manually to gain access to my stuff. I mean, this is the point, it's encrypted. And in any case there would be an opt out for encryption. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 02, 2019 at 06:16:43PM +, Zbigniew Jędrzejewski-Szmek wrote: ...snip... > Nevertheless, I'm pretty sure that a workaround for this will be made > anyway. I think the latest version of the patchset allows exporting > the authorized_keys content in the non-encrypted metadata for the user. I wonder if clevis/tang could help here? ( https://github.com/latchset/clevis ) It could allow decryption in home networks, but not when traveling. Of course you would have to setup the server, etc. kevin 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 2, 2019 at 10:45 AM John M. Harris Jr wrote: > > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote: > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > >> Mabee systemd-homed is in > > >> a position to solve this by having early enough authentication > > >> capability by rescue.target time that any admin user can login? > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > > implemented together with changes to how user metadata querying is done: > > > instead of using dbus, a brokerless and much simpler varlink query is > > > used. > > > That last part is what would be relevant to early-boot logins, because > > > less services need to be up to bring up the user session. > > > > There's one tricky feature of homed : remote login (ssh) is only > > possible after an initial local login. It is OK for his intended use (a > > personal laptop/tablet client), except for corner cases like a remotely > > accessed personal desktop in the basement that might get rebooted e.g. > > for updates, resulting in an accidental lockout. > > Basically, systemd-homed is useless for any power user, but might be useful > for people just getting into GNU/Linux, who don't use ssh yet or don't have > more than one system. I disagree with all of this, including the predisposition that this limitation can't be worked around somehow. I ssh into various laptops around the home office on a daily basis, I'm not going to give that up. Based on the systemd-homed presentation, slides, and the early code review happening, it addresses a number of concerns the Workstation WG has in making forward progress to secure user data by default. It's almost 2020, and I shouldn't have to pick and choose between remote access and securing user data at rest by default. We surely can have our cake and eat it too. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel wrote: > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > Mabee systemd-homed is in > a position to solve this by having early enough authentication > capability by rescue.target time that any admin user can login? > > Actually, it may. Things are confusing here, because systemd-homed is > implemented together with changes to how user metadata querying is done: > instead of using dbus, a brokerless and much simpler varlink query is used. > That last part is what would be relevant to early-boot logins, because > less services need to be up to bring up the user session. > > There's one tricky feature of homed : remote login (ssh) is only possible > after an initial local login. It is OK for his intended use (a personal > laptop/tablet client), except for corner cases like a remotely accessed > personal desktop in the basement that might get rebooted e.g. for updates, > resulting in an accidental lockout. It's not just an issue for systemd-homed, this problem applies to any user home encryption implementation when the user has not first authenticated/unlocked their user home. e.g. if you install with /home encrypted in Anaconda, in fact your boot stops at plymouth in the initramfs so sshd is thwarted from even starting in the first place; and even if GNOME Shell's login were to be enhanced to do this unlock, still requires unlock. Basically you have to choose between user home security (or more specifically privacy) and remote logins. However, there are some ideas that could possibly work around this, to varying degrees of inelegance, which I'll gratuitously copy from a related Workstation WG issue [1]. 1. Enhance openssh's PAM support 2. Stub account to ssh into, whereby the user is prompted to authenticate+unlock the real account; and now ssh into the real account. 3. Same as 2 but maybe it's possible to bind mount the real home dir over the stub home dir, eliminating the 2nd login? (Vaguely recall reading about this somewhere, maybe Ubuntu's use of ecryptfs based home, now since deprecated in favor of LUKS) 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption [1] https://pagure.io/fedora-workstation/issue/82#comment-614193 -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 2019-12-02 at 18:16 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote: > > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel > > wrote: > > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > > > > Mabee systemd-homed is in > > > > > a position to solve this by having early enough authentication > > > > > capability by rescue.target time that any admin user can login? > > > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > > > implemented together with changes to how user metadata querying is done: > > > > instead of using dbus, a brokerless and much simpler varlink query is > > > > used. > > > > That last part is what would be relevant to early-boot logins, because > > > > less services need to be up to bring up the user session. > > > > > > There's one tricky feature of homed : remote login (ssh) is only > > > possible after an initial local login. It is OK for his intended use (a > > > personal laptop/tablet client), except for corner cases like a remotely > > > accessed personal desktop in the basement that might get rebooted e.g. > > > for updates, resulting in an accidental lockout. > > > > Basically, systemd-homed is useless for any power user, but might be useful > > for people just getting into GNU/Linux, who don't use ssh yet or don't have > > more than one system. > > How often do you ssh *into* your laptop? Actually all the time - my (personal home) laptop is where my hobby projects live, where various SSH private keys are, etc. So I SSH there to connect to another machine using the SSH keys, to work an my hobby projects from a workstation computer at home, etc. And this is just "human" SSH sessions, various automated rsync/scp connections might happen as well. > I occasionally do, but more > because I can than because I really need to. systemd-homed is most > suited for the case of a portable personal device, and this is exactly > the type of device one is relatively unlikely to access from the > network. So I don't think this limitation is so terrible. > > Nevertheless, I'm pretty sure that a workaround for this will be made > anyway. I think the latest version of the patchset allows exporting > the authorized_keys content in the non-encrypted metadata for the user. > > 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 ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Le lundi 02 décembre 2019 à 18:16 +, Zbigniew Jędrzejewski-Szmek a écrit : > > How often do you ssh *into* your laptop? I use the same tech desktop and home server side. If it does not work on my home server, I don’t want to see it on my desktops. I have other things to do in life than coping with Linux systems fragmentation. Trying to invent desktop-only things, when the Linux desktop market share is marginal, and a large part of this marginal userbase is people also working on Linux servers, is not likely to succeed. Regards, -- Nicolas Mailhot ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote: > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote: > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > >> Mabee systemd-homed is in > > >> a position to solve this by having early enough authentication > > >> capability by rescue.target time that any admin user can login? > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > > implemented together with changes to how user metadata querying is done: > > > instead of using dbus, a brokerless and much simpler varlink query is > > > used. > > > That last part is what would be relevant to early-boot logins, because > > > less services need to be up to bring up the user session. > > > > There's one tricky feature of homed : remote login (ssh) is only > > possible after an initial local login. It is OK for his intended use (a > > personal laptop/tablet client), except for corner cases like a remotely > > accessed personal desktop in the basement that might get rebooted e.g. > > for updates, resulting in an accidental lockout. > > Basically, systemd-homed is useless for any power user, but might be useful > for people just getting into GNU/Linux, who don't use ssh yet or don't have > more than one system. How often do you ssh *into* your laptop? I occasionally do, but more because I can than because I really need to. systemd-homed is most suited for the case of a portable personal device, and this is exactly the type of device one is relatively unlikely to access from the network. So I don't think this limitation is so terrible. Nevertheless, I'm pretty sure that a workaround for this will be made anyway. I think the latest version of the patchset allows exporting the authorized_keys content in the non-encrypted metadata for the user. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote: > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > >> Mabee systemd-homed is in > >> a position to solve this by having early enough authentication > >> capability by rescue.target time that any admin user can login? > > > > Actually, it may. Things are confusing here, because systemd-homed is > > implemented together with changes to how user metadata querying is done: > > instead of using dbus, a brokerless and much simpler varlink query is > > used. > > That last part is what would be relevant to early-boot logins, because > > less services need to be up to bring up the user session. > > There's one tricky feature of homed : remote login (ssh) is only > possible after an initial local login. It is OK for his intended use (a > personal laptop/tablet client), except for corner cases like a remotely > accessed personal desktop in the basement that might get rebooted e.g. > for updates, resulting in an accidental lockout. Basically, systemd-homed is useless for any power user, but might be useful for people just getting into GNU/Linux, who don't use ssh yet or don't have more than one system. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: Mabee systemd-homed is in a position to solve this by having early enough authentication capability by rescue.target time that any admin user can login? Actually, it may. Things are confusing here, because systemd-homed is implemented together with changes to how user metadata querying is done: instead of using dbus, a brokerless and much simpler varlink query is used. That last part is what would be relevant to early-boot logins, because less services need to be up to bring up the user session. There's one tricky feature of homed : remote login (ssh) is only possible after an initial local login. It is OK for his intended use (a personal laptop/tablet client), except for corner cases like a remotely accessed personal desktop in the basement that might get rebooted e.g. for updates, resulting in an accidental lockout. ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 09:53:49AM -0600, Michael Catanzaro wrote: > On Tue, Nov 26, 2019 at 9:35 am, Chris Adams wrote: > >That should be considered a bug IMHO... > > At least for rescue mode, probably yes, but I don't know what to do > about it. Can we make systemd's rescue prompt ask for username and > allow logging in with any user account (goal being to log in to > admin account then 'sudo -i')? Or would there be problems with that? > Clearly it's not designed for that purpose, and it seems > intentional. systemd does not implement user authentication by itself: it just spawns getty/gdm/etc during normal runtime, and sulogin for emergency logins. We generally do not want to re-implement this functionality in systemd. selinux has some special permissions for sulogin, etc. Ideally, sulogin would get the capability to pick an alternative user. util-linux already has the code to select and authenticate users, so it'd be just a question of some design work and rearranging the code. On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > Mabee systemd-homed is in > a position to solve this by having early enough authentication > capability by rescue.target time that any admin user can login? Actually, it may. Things are confusing here, because systemd-homed is implemented together with changes to how user metadata querying is done: instead of using dbus, a brokerless and much simpler varlink query is used. That last part is what would be relevant to early-boot logins, because less services need to be up to bring up the user session. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, November 26, 2019 8:53:49 AM MST Michael Catanzaro wrote: > On Tue, Nov 26, 2019 at 9:35 am, Chris Adams wrote: > > > That should be considered a bug IMHO... > > > At least for rescue mode, probably yes, but I don't know what to do > about it. Can we make systemd's rescue prompt ask for username and > allow logging in with any user account (goal being to log in to admin > account then 'sudo -i')? Or would there be problems with that? Clearly > it's not designed for that purpose, and it seems intentional. That would not work in 99% of scenarios that require rescue, especially with most networks employing network authentication, which would not be available. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, November 26, 2019 8:10:49 AM MST Michael Catanzaro wrote: > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: > > > How does that work with single-user mode, rescue mode, etc.? > > > I assume single-user mode does not work. Rescue mode certainly does not > work. It asks for a root password, but root account is locked. > > Michael The easiest method is to just do `rw init=/bin/bash` and do what you need to do. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Dominique Martinet wrote: > They just expected no root password = no login possible, but it turns > out 'su' just gave out a root shell with no password entered... Then they need to RTFM of passwd. The correct way to block password login for an account is passwd -l, not passwd -d. Even passwd --help explicitly documents -d as removing the password lock, not adding it. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 9:48 AM Chris Adams wrote: > > Once upon a time, Chris Murphy said: > > On Tue, Nov 26, 2019 at 8:36 AM Chris Adams wrote: > > > > > > Once upon a time, Michael Catanzaro said: > > > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: > > > > >How does that work with single-user mode, rescue mode, etc.? > > > > > > > > I assume single-user mode does not work. Rescue mode certainly does > > > > not work. It asks for a root password, but root account is locked. > > > > > > That should be considered a bug IMHO... > > > > I brought this up ages ago. Basically emergency.target and > > rescue.target have a hard requirement on root, and there aren't enough > > services present to authenticate some other user (I guess?). And on > > Workstation, it was long ago decided to not require setting up a root > > user at install time *if* an (admin) user were setup. And that was > > followed up more recently by eliminating the install time user setup > > entirely, on Workstation edition. > > > > So...it's a difficult problem to solve. Mabee systemd-homed is in > > a position to solve this by having early enough authentication > > capability by rescue.target time that any admin user can login? > > You can't guarantee that a non-root admin user even exists at > single/rescue mode time, since they could all be network authentication. Good point. > I'd suggest switching back to not requiring a password for single/rescue > mode by default; there's not a default boot-loader password requirement, > so it's not like the single/rescue root password can't be bypassed > already. Yeah I forget the rationale for this. Since there's no bootloader lockdown, and it's trivial to just add systemd.debug-shell=1 I can get a tty with root user active and not even need a password, for any target, including multi-user and graphical. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Nov 25, 2019 at 2:26 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault > > == Summary == > Remove ''nullok'' parameter from pam_unix module in default PAM > configuration in order to disallow authentication with empty password. How difficult is it to apply this change (disallow authentication for user with empty password) to only root and users in the wheel group? i.e. permit empty password standard users (not in wheel)? > Current default configuration allows users to login with an empty > password by setting nullok parameter to pam_unix module. This affects > only logins to local machine, it does not affect ssh logins as this > must be explicitly allowed in sshd_config. We want to disallow empty > password by default for local logins as well to improve system > hardening. At least out of the box on Fedora Workstation it's non-trivial to get into this situation, you have to know what you're doing. The root user has sp_pwdp set to ! and neither GNOME Initial Setup nor the GNOME Settings: Users panel permits an empty passphrase. Anyway, there is also a lot of other implied work with this feature that I wonder if feature owners should evaluate the implications of a possible future adoption of systemd-homed? That's a new feature in systemd-244, and is something the Workstation WG is evaluating as part of enabling user home encryption by default. The main thing systemd-homed brings to the table is a cleaner authentication paradigm, with user home encryption as a (recommended) option which systemd-homed also manages. I'll start a separate thread about homed, but since it touches on authentication and so does this feature proposal, I think it's relevant to bring attention to it. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Once upon a time, Chris Murphy said: > On Tue, Nov 26, 2019 at 8:36 AM Chris Adams wrote: > > > > Once upon a time, Michael Catanzaro said: > > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: > > > >How does that work with single-user mode, rescue mode, etc.? > > > > > > I assume single-user mode does not work. Rescue mode certainly does > > > not work. It asks for a root password, but root account is locked. > > > > That should be considered a bug IMHO... > > I brought this up ages ago. Basically emergency.target and > rescue.target have a hard requirement on root, and there aren't enough > services present to authenticate some other user (I guess?). And on > Workstation, it was long ago decided to not require setting up a root > user at install time *if* an (admin) user were setup. And that was > followed up more recently by eliminating the install time user setup > entirely, on Workstation edition. > > So...it's a difficult problem to solve. Mabee systemd-homed is in > a position to solve this by having early enough authentication > capability by rescue.target time that any admin user can login? You can't guarantee that a non-root admin user even exists at single/rescue mode time, since they could all be network authentication. I'd suggest switching back to not requiring a password for single/rescue mode by default; there's not a default boot-loader password requirement, so it's not like the single/rescue root password can't be bypassed already. I actually had that as part of my personal setup scripts for a while, until now systemd removed the unit files and went to an undocumented wrapper binary. There should be a documented way to enable the password requirement (and then how to handle it, setting a root password, setting a boot-loader password, anything else required). But it is really IMHO kind of silly to have it there by default. -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 8:36 AM Chris Adams wrote: > > Once upon a time, Michael Catanzaro said: > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: > > >How does that work with single-user mode, rescue mode, etc.? > > > > I assume single-user mode does not work. Rescue mode certainly does > > not work. It asks for a root password, but root account is locked. > > That should be considered a bug IMHO... I brought this up ages ago. Basically emergency.target and rescue.target have a hard requirement on root, and there aren't enough services present to authenticate some other user (I guess?). And on Workstation, it was long ago decided to not require setting up a root user at install time *if* an (admin) user were setup. And that was followed up more recently by eliminating the install time user setup entirely, on Workstation edition. So...it's a difficult problem to solve. Mabee systemd-homed is in a position to solve this by having early enough authentication capability by rescue.target time that any admin user can login? -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, 2019-11-26 at 08:14 -0800, Adam Williamson wrote: > On Tue, 2019-11-26 at 09:45 +0100, Dominique Martinet wrote: > > Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800: > > > I gotta say +1 too. I don't buy that there's a significant 'hardening' > > > benefit worth all the effort mentioned in the Change *plus* the > > > additional consequences Kevin and Martin pointed out. At minimum I'd > > > like to see a much more convincing case that people are creating users > > > without passwords without understanding what they're doing. > > > > FWIW this has happened at an association I help at -- they had VMs with > > no root password set, and users created by puppet some of whom have > > sudo. > > They just expected no root password = no login possible, but it turns > > out 'su' just gave out a root shell with no password entered... > > Uh. This sounds odd. How exactly did they do this? Making a root > account with no password is not that easy; you can't do it > interactively through anaconda, I don't even know if you can do it with > a kickstart. So they figured out how to do it post-install but somehow > didn't at the same time figure out what doing it means? Never mind, I see this was answered already. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, 2019-11-26 at 09:45 +0100, Dominique Martinet wrote: > Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800: > > I gotta say +1 too. I don't buy that there's a significant 'hardening' > > benefit worth all the effort mentioned in the Change *plus* the > > additional consequences Kevin and Martin pointed out. At minimum I'd > > like to see a much more convincing case that people are creating users > > without passwords without understanding what they're doing. > > FWIW this has happened at an association I help at -- they had VMs with > no root password set, and users created by puppet some of whom have > sudo. > They just expected no root password = no login possible, but it turns > out 'su' just gave out a root shell with no password entered... Uh. This sounds odd. How exactly did they do this? Making a root account with no password is not that easy; you can't do it interactively through anaconda, I don't even know if you can do it with a kickstart. So they figured out how to do it post-install but somehow didn't at the same time figure out what doing it means? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 9:35 am, Chris Adams wrote: That should be considered a bug IMHO... At least for rescue mode, probably yes, but I don't know what to do about it. Can we make systemd's rescue prompt ask for username and allow logging in with any user account (goal being to log in to admin account then 'sudo -i')? Or would there be problems with that? Clearly it's not designed for that purpose, and it seems intentional. ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Once upon a time, Michael Catanzaro said: > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: > >How does that work with single-user mode, rescue mode, etc.? > > I assume single-user mode does not work. Rescue mode certainly does > not work. It asks for a root password, but root account is locked. That should be considered a bug IMHO... -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 9:45 am, Dominique Martinet
wrote:
They just expected no root password = no login possible, but it turns
out 'su' just gave out a root shell with no password entered...
It depends on whether the account is locked or not. In Workstation we
default to locked passwordless root, equivalent to:
# passwd -d root
# passwd -l root
which is what your association really wanted to do with their VMs: no
root password, and cannot log in as root. They forgot the 'passwd -l',
without which you're able to log in as root with no password. ('passwd
-d' removes the password and unlocks the account; 'passwd -l' locks it.)
Michael
___
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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 8:03 am, Chris Adams wrote: How does that work with single-user mode, rescue mode, etc.? I assume single-user mode does not work. Rescue mode certainly does not work. It asks for a root password, but root account is locked. Michael ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Once upon a time, David Kaufmann said: > At least with Fedora 31 the root-Password is invalid by default, so I > guess it has been set to an empty password explicitely. How does that work with single-user mode, rescue mode, etc.? In the past, you could change the options to /sbin/sulogin, but systemd apparently absorbed or wraps that functionality with its own thing, /usr/lib/systemd/systemd-sulogin-shell, that doesn't appear to be documented (at least in the man pages). -- 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
26.11.2019, 11:39, "Zbigniew Jędrzejewski-Szmek" : > On Mon, Nov 25, 2019 at 03:55:28PM -0800, Adam Williamson wrote: >> On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote: >> > Samuel Sieb wrote: >> > > Steps 1 - 4 are not benefits, they are workarounds to critical system >> > > utilities required by this change. I don't understand why this change >> > > is necessary at all. It only affects local logins and if someone wants >> > > to have an empty password, why make it so difficult? It's their choice. >> > >> > +1, I do not see the point of patronizing our users that way (and it is >> only >> > an extra hoop to jump through because they can still readd the nullok), >> and >> > find it particularly pointless to make all those error-prone changes to >> core >> > system utilities just to make that work. >> > >> > > It's not like Fedora has any default logins with empty passwords, the >> > > user has to make their own. >> > >> > That part is actually not entirely true: the live images have no password >> > set on the liveuser and root accounts. Hence, this change will also break >> > the live images, unless we add yet another hack to the scriptlets in the >> > live kickstarts, one that readds the nullok option. IMHO, we already have >> > too many hacks in the kickstart scriptlets. >> >> I gotta say +1 too. I don't buy that there's a significant 'hardening' >> benefit worth all the effort mentioned in the Change *plus* the >> additional consequences Kevin and Martin pointed out. At minimum I'd >> like to see a much more convincing case that people are creating users >> without passwords without understanding what they're doing. > > +1 from me too. It is very convenient to be able to set an empty password > on certains VMs and containers and special-purpose machines. > > I would support this change if there were plausible scenarios where the > password is unset by mistake. But the only case cited so far is the puppet > mistake where the admins scripted 'passwd -d root' and then forgot about > this. This is not a fight we could ever win: if we remove 'nullok', > the admins would simply add another script line to add it back. Agreed. I too am against this change for the reasons other people have already stated. Pete ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Nov 25, 2019 at 03:55:28PM -0800, Adam Williamson wrote: > On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote: > > Samuel Sieb wrote: > > > Steps 1 - 4 are not benefits, they are workarounds to critical system > > > utilities required by this change. I don't understand why this change > > > is necessary at all. It only affects local logins and if someone wants > > > to have an empty password, why make it so difficult? It's their choice. > > > > +1, I do not see the point of patronizing our users that way (and it is > > only > > an extra hoop to jump through because they can still readd the nullok), and > > find it particularly pointless to make all those error-prone changes to > > core > > system utilities just to make that work. > > > > > It's not like Fedora has any default logins with empty passwords, the > > > user has to make their own. > > > > That part is actually not entirely true: the live images have no password > > set on the liveuser and root accounts. Hence, this change will also break > > the live images, unless we add yet another hack to the scriptlets in the > > live kickstarts, one that readds the nullok option. IMHO, we already have > > too many hacks in the kickstart scriptlets. > > I gotta say +1 too. I don't buy that there's a significant 'hardening' > benefit worth all the effort mentioned in the Change *plus* the > additional consequences Kevin and Martin pointed out. At minimum I'd > like to see a much more convincing case that people are creating users > without passwords without understanding what they're doing. +1 from me too. It is very convenient to be able to set an empty password on certains VMs and containers and special-purpose machines. I would support this change if there were plausible scenarios where the password is unset by mistake. But the only case cited so far is the puppet mistake where the admins scripted 'passwd -d root' and then forgot about this. This is not a fight we could ever win: if we remove 'nullok', the admins would simply add another script line to add it back. 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tuesday, November 26, 2019 3:31:54 AM MST Kamil Paral wrote: > On Mon, Nov 25, 2019 at 10:27 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault > > > > == Summary == > > Remove ''nullok'' parameter from pam_unix module in default PAM > > configuration in order to disallow authentication with empty password. > > > > == Owner == > > * Name: [[User:pbrezina| Pavel Březina]] > > * Email: > > > > == Detailed Description == > > > > Current default configuration allows users to login with an empty > > password by setting nullok parameter to pam_unix module. This affects > > only logins to local machine, it does not affect ssh logins as this > > must be explicitly allowed in sshd_config. We want to disallow empty > > password by default for local logins as well to improve system > > hardening. > > It makes sense to implement this functionality so that users/admins can > harden their systems in this way if they prefer. But I don't think it > should be the default all across Fedora. Especially in desktop space, empty > passwords make sense. I think the best approach would be to provide the > functionality and then let individual spins/editions enable this by default > if they want (e.g. the Security spin, or Server). Let me clarify something I said earlier in this thread. I don't believe anyone should be using empty passwords. That said, I know that there's no way I can convince certain people to use a password, and those people would still like to be able to use Fedora without having to learn pam configuration. I don't believe that empty passwords make sense in any case. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Nov 25, 2019 at 10:27 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault > > == Summary == > Remove ''nullok'' parameter from pam_unix module in default PAM > configuration in order to disallow authentication with empty password. > > == Owner == > * Name: [[User:pbrezina| Pavel Březina]] > * Email: > > == Detailed Description == > > Current default configuration allows users to login with an empty > password by setting nullok parameter to pam_unix module. This affects > only logins to local machine, it does not affect ssh logins as this > must be explicitly allowed in sshd_config. We want to disallow empty > password by default for local logins as well to improve system > hardening. > It makes sense to implement this functionality so that users/admins can harden their systems in this way if they prefer. But I don't think it should be the default all across Fedora. Especially in desktop space, empty passwords make sense. I think the best approach would be to provide the functionality and then let individual spins/editions enable this by default if they want (e.g. the Security spin, or Server). ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
David Kaufmann wrote on Tue, Nov 26, 2019 at 11:13:15AM +0100: > On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote: > > FWIW this has happened at an association I help at -- they had VMs with > > no root password set, and users created by puppet some of whom have > > sudo. > > They just expected no root password = no login possible, but it turns > > out 'su' just gave out a root shell with no password entered... > > > > It's easy to fix once I realized that, but it had been that way for > > quite a while until then; I'd definitely support removing nullok on the > > default install. > > At least with Fedora 31 the root-Password is invalid by default, so I > guess it has been set to an empty password explicitely. > I'd classify this more as a bug in the puppet-scripts, as it sounds like > it touched security relevant stuff on installation, without admins being > aware of it. Yes, definitely. I'm pretty sure puppet didn't touch it, but they must have set the root password to an empty string somewhere on deployment -- I found it now I'm looking, they run 'passwd -d root' in the image on purpose apparently (don't ask me why...), and people who had done it left and turnover happened and new people weren't aware of it. I really just wanted to answer Adam's "does it really happen?" question - it does. Would the change have been enough to make whoever removed the root password not also re-add nullok ? I don't know, but it might have made them think about it twice and reconsider doing that. In an ideal world I think most people would consider passwordless login ok if you're on the console or a physical seat, and not ok if you come from ssh or some script running somewhere (cgi or whatever). Is that attainable ? -- Dominique ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote: > FWIW this has happened at an association I help at -- they had VMs with > no root password set, and users created by puppet some of whom have > sudo. > They just expected no root password = no login possible, but it turns > out 'su' just gave out a root shell with no password entered... > > It's easy to fix once I realized that, but it had been that way for > quite a while until then; I'd definitely support removing nullok on the > default install. At least with Fedora 31 the root-Password is invalid by default, so I guess it has been set to an empty password explicitely. I'd classify this more as a bug in the puppet-scripts, as it sounds like it touched security relevant stuff on installation, without admins being aware of it. All the best, David 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Samuel Sieb wrote on Tue, Nov 26, 2019 at 01:38:51AM -0800: > >FWIW this has happened at an association I help at -- they had VMs with > >no root password set, and users created by puppet some of whom have > >sudo. > >They just expected no root password = no login possible, but it turns > >out 'su' just gave out a root shell with no password entered... > > "su" or "sudo"? Your scenario is unclear. both worked -- that is the point, su should not have worked here. They basically gave root access to everyone, regardless of sudoer settings. > >It's easy to fix once I realized that, but it had been that way for > >quite a while until then; I'd definitely support removing nullok on the > >default install. > > I don't think that this proposal would even help with that situation. This > is about user passwords, not root. How were those VMs created? Whatever the virtualization solution they use to create VMs, it just had an empty root password. I haven't checked what is used, I agree it also is a bug in their setup script (fixed since then), but there are plenty of scenarii where an empty root password makes sense for VMs/containers e.g. allow logins from the console by default, so I believe these will continue to do that. > If you're creating users with sudo access, how can you not expect to > have root be accessible? It sure would... I didn't say root user should be locked out to sudoers, just 'su' shouldn't work. An alternative might be to go back to securetty settings allowing console login but not non-interactive su or su over ssh. That does sound harder to setup/easier to miss, though, and if someone does set a root password up they would be doubly surprised... I don't think we can tell it to only look at securetty if the password was empty? -- Dominique ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 11/26/19 12:45 AM, Dominique Martinet wrote: Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800: I gotta say +1 too. I don't buy that there's a significant 'hardening' benefit worth all the effort mentioned in the Change *plus* the additional consequences Kevin and Martin pointed out. At minimum I'd like to see a much more convincing case that people are creating users without passwords without understanding what they're doing. FWIW this has happened at an association I help at -- they had VMs with no root password set, and users created by puppet some of whom have sudo. They just expected no root password = no login possible, but it turns out 'su' just gave out a root shell with no password entered... "su" or "sudo"? Your scenario is unclear. It's easy to fix once I realized that, but it had been that way for quite a while until then; I'd definitely support removing nullok on the default install. I don't think that this proposal would even help with that situation. This is about user passwords, not root. How were those VMs created? If you're creating users with sudo access, how can you not expect to have root be accessible? ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800: > I gotta say +1 too. I don't buy that there's a significant 'hardening' > benefit worth all the effort mentioned in the Change *plus* the > additional consequences Kevin and Martin pointed out. At minimum I'd > like to see a much more convincing case that people are creating users > without passwords without understanding what they're doing. FWIW this has happened at an association I help at -- they had VMs with no root password set, and users created by puppet some of whom have sudo. They just expected no root password = no login possible, but it turns out 'su' just gave out a root shell with no password entered... It's easy to fix once I realized that, but it had been that way for quite a while until then; I'd definitely support removing nullok on the default install. -- Dominique ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 25 Nov 2019 22:59:18 +0100, Samuel Sieb wrote: > I don't understand why this change is > necessary at all. It only affects local logins and if someone wants to have > an empty password, why make it so difficult? It's their choice. It's not > like Fedora has any default logins with empty passwords, the user has to > make their own. Yes, what about firewalled virtual machines for development testing purposes? There any password makes no sense. Jan ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Hi, Setting aside the question of how anaconda, gnome-initial-setup, and the liveuser sessions would work, I have a question about the complaint regarding accountsservice. On Mon, Nov 25, 2019 at 4:25 pm, Ben Cotton wrote: * '''AccountService''' - D-Bus methods ''SetPassword'' and ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can remove user’s password and lock the user out of the system if empty password is disallowed. These calls must be denied in this case. OK, makes sense. But: Additionally, these methods can be run by normal users as opposed to ''passwd -d'' and ''chage -d 0'' which can be run only by root. Therefore only root should be able to call these methods. So... then users can't change their own passwords? We don't enable root account in Workstation anyway, it would become impossible to ever change any password via accountsservice. Let's assume you meant "only admin users should be able to call these methods" instead of "only root". Even then, I still don't understand the problem. I just tested using D-Feet to manually change my password using org.freedesktop.Accounts SetPassword, and it required that I authenticate via polkit. polkit is good; let it do its thing. It's checking the org.freedesktop.accounts.change-own-password action, which requires auth_admin authentication. So what is the problem here? Michael ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote: > Samuel Sieb wrote: > > Steps 1 - 4 are not benefits, they are workarounds to critical system > > utilities required by this change. I don't understand why this change > > is necessary at all. It only affects local logins and if someone wants > > to have an empty password, why make it so difficult? It's their choice. > > +1, I do not see the point of patronizing our users that way (and it is only > an extra hoop to jump through because they can still readd the nullok), and > find it particularly pointless to make all those error-prone changes to core > system utilities just to make that work. > > > It's not like Fedora has any default logins with empty passwords, the > > user has to make their own. > > That part is actually not entirely true: the live images have no password > set on the liveuser and root accounts. Hence, this change will also break > the live images, unless we add yet another hack to the scriptlets in the > live kickstarts, one that readds the nullok option. IMHO, we already have > too many hacks in the kickstart scriptlets. I gotta say +1 too. I don't buy that there's a significant 'hardening' benefit worth all the effort mentioned in the Change *plus* the additional consequences Kevin and Martin pointed out. At minimum I'd like to see a much more convincing case that people are creating users without passwords without understanding what they're doing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
Samuel Sieb wrote: > Steps 1 - 4 are not benefits, they are workarounds to critical system > utilities required by this change. I don't understand why this change > is necessary at all. It only affects local logins and if someone wants > to have an empty password, why make it so difficult? It's their choice. +1, I do not see the point of patronizing our users that way (and it is only an extra hoop to jump through because they can still readd the nullok), and find it particularly pointless to make all those error-prone changes to core system utilities just to make that work. > It's not like Fedora has any default logins with empty passwords, the > user has to make their own. That part is actually not entirely true: the live images have no password set on the liveuser and root accounts. Hence, this change will also break the live images, unless we add yet another hack to the scriptlets in the live kickstarts, one that readds the nullok option. IMHO, we already have too many hacks in the kickstart scriptlets. Kevin Kofler ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 2019-11-25 at 16:25 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>
> == Summary ==
> Remove ''nullok'' parameter from pam_unix module in default PAM
> configuration in order to disallow authentication with empty password.
>
> == Owner ==
> * Name: [[User:pbrezina| Pavel Březina]]
> * Email:
>
> == Detailed Description ==
>
> Current default configuration allows users to login with an empty
> password by setting nullok parameter to pam_unix module. This affects
> only logins to local machine, it does not affect ssh logins as this
> must be explicitly allowed in sshd_config. We want to disallow empty
> password by default for local logins as well to improve system
> hardening.
>
> Note: It is possible to disallow empty passwords with authselect call
> (authselect enable-feature without-nullok) or by removing nullok
> manually, however it creates possible issues in other components that
> must be addressed.
>
> === Affected Components ===
> * '''passwd''' - calling passwd -d to remove users password must be
> denied if empty passwords are disallowed otherwise the user will be
> locked out of the system
> * '''AccountService''' - D-Bus methods ''SetPassword'' and
> ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
> remove user’s password and lock the user out of the system if empty
> password is disallowed. These calls must be denied in this case.
> Additionally, these methods can be run by normal users as opposed to
> ''passwd -d'' and ''chage -d 0'' which can be run only by root.
> Therefore only root should be able to call these methods.
> * '''Gnome’s Control Center''' - when creating new users, it provides
> an option to “require password to be set on first login” which creates
> user with expired empty password. This would again lock the user out
> of the system.
> * '''Other Desktop Environments''' - may have the same issue as Gnome
> Control Center
This would definitely also affect the installation, unless we want to create
user accounts
that can't log in.
So the list of affected components should include also Anaconda and Gnome
Initial Setup.
>
> === Solution Step by Step ===
>
> Step 1) Provide a unified way to read if nullok is enabled or not
>
> We will create an authselect library call that would parse existing
> PAM configuration (not necessarily generated by authselect) and return
> list of enabled/disabled features. We will implement only ''nullok''
> feature in the scope of this change but if needed it can be extended
> in the future.
>
> Step 2) Fix passwd -d
> Calling ''passwd -d'' to remove user's password will fail if
> ''nullok'' is disabled.
>
> Step 3) Fix AccountService
> These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
> will be callable only by ''root'' and must return an error if
> ''nullok'' is disabled.
>
> SetPasswordMode
> SetPassword(“”, hint)
>
> Step 4) Fix Desktop Environments
> “Require password change on next login” must keep working. This
> feature currently relies on setting an empty password. A new option
> ''nullresetok'' will be implemented for ''pam_unix'' module that will
> allow user to authenticate with empty password only if a password
> change for this user is enforced upon login. Authentication with empty
> passwords which are not expired will be prohibited (unless ''nullok''
> is set).
>
> Step 5) Update PAM configuration to disable nullok by default
> In authselect and pam components for new installations. Upgrading from
> older systems will keep nullok present.
>
> == Benefit to Fedora ==
>
> Changes in described components (Step 1 - Step 4) are necessary to
> implement in order to make sure that user accounts and tools works
> correctly when authentication with empty password is disabled by
> system administrator. Changing system default to disallow
> authentication with empty passwords (Step 5) improves system
> hardening.
>
> == Scope ==
> * Proposal owners: Coordinate the work. Make sure all required changes
> are implemented.
> * Other developers: All affected component must be fixed. Changes are
> described in ''Detailed Description''
> * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
> check of an impact with Release Engineering is needed)
>
>
> * Policies and guidelines: No updates needed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> This does not affect system upgrades because only new installation
> will have changed default.
>
> == How To Test ==
>
> * Calling ''passwd -d user'' as root must fail with default configuration.
> * Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
> ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
> default configuration.
> * "require password reset on first login" must keep working when
> creating users from Desktop
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Monday, November 25, 2019 2:59:18 PM MST Samuel Sieb wrote: > On 11/25/19 1:25 PM, Ben Cotton wrote: > > > == Benefit to Fedora == > > > > Changes in described components (Step 1 - Step 4) are necessary to > > implement in order to make sure that user accounts and tools works > > correctly when authentication with empty password is disabled by > > system administrator. Changing system default to disallow > > authentication with empty passwords (Step 5) improves system > > hardening. > > > Steps 1 - 4 are not benefits, they are workarounds to critical system > utilities required by this change. I don't understand why this change > is necessary at all. It only affects local logins and if someone wants > to have an empty password, why make it so difficult? It's their choice. > It's not like Fedora has any default logins with empty passwords, the > user has to make their own. > ___ > 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 I would have to agree. It's one thing to warn non-technical users when setting empty passwords, another entirely to prevent them. Many non-technical users just don't want a password set on their system. -- John M. Harris, Jr. Splentity ___ 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
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On 11/25/19 1:25 PM, Ben Cotton wrote: == Benefit to Fedora == Changes in described components (Step 1 - Step 4) are necessary to implement in order to make sure that user accounts and tools works correctly when authentication with empty password is disabled by system administrator. Changing system default to disallow authentication with empty passwords (Step 5) improves system hardening. Steps 1 - 4 are not benefits, they are workarounds to critical system utilities required by this change. I don't understand why this change is necessary at all. It only affects local logins and if someone wants to have an empty password, why make it so difficult? It's their choice. It's not like Fedora has any default logins with empty passwords, the user has to make their own. ___ 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
