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
>
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
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
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
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
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
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
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
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"?
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
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
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
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: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
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,
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
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
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
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:
> > >
> > > >
> > > >
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
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,
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
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
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
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
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
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
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
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
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
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 :
-
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
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
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
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
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.
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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:
> >
> >
> >
>
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
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
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
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
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
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
>
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>> > >
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
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
> >
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 ==
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.
> >
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
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
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
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
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
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
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
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
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
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
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
101 - 193 of 193 matches
Mail list logo
