Summary of password strength discussion

[Chris Murphy]

On Tue, Jul 28, 2015 at 11:09 AM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Tue, Jul 28, 2015 at 10:52:02AM -0600, Chris Murphy wrote:
>> > Oh! An alternative which avoids any file parsing or writing: add an
>> > "ssh-access" or similar group, configure default sshd_config with
>> > "AllowGroups ssh-access". (Could be a Workstation-only sshd_config.)
>> Maybe. Elsewhere I read that AllowUsers overrides AllowGroups. So as
>> soon as you have AllowUsers chris, it basically ignores AllowGroups
>> and only allows chris. But that's goofy if true.
>
> I think both goofy and true, but also not necessarily a problem - in
> fact, maybe actually it's exactly what we want, since it's a sort of
> "fail-secure" - it means that if someone wants to restrict to just
> certain users manually, they won't be surprised by AllowGroups
> overriding it.

I'm pretty sure it's AllowUsers overrides AllowGroups not vice versa.

Ergo if an existing sshd_config has AllowGroups configured, then GUI
modification of sshd_config would have to do one of two things:
a. Use AllowUsers would then break existing AllowGroups;
b. Use existing AllowGroups by parsing it for the custom group name,
and adding users to that custom group.

Blek.



(I guess the remote-login switch code could _warn_ if
> this is detected in an existing config file. Or even just warn if the
> config file is not default.)

Yeah that's kinda icky. I'd say sshd_config ought to be untouched if
at all possible. Upgrades should rename the old one, and install a new
default one. And hopefully there's a way for the GUI to leverage PAM
for sshd authentication per user.

Over on OS X, it has a UI that all users can see but only an
authenticated admin can modify, to allow ssh for all users, by group,
or by user. Changes in that UI do not modify sshd_config. But
sshd_config also has #UsePAM yes, so I'm assuming they are not using
PAM but have some other way of doing authentication and account
restriction. I know that sshd_config is still honored though because
on my mom's laptop I've disabled password based logins and can only
use PKA.



>
>> But my gut instinct is that sharing services UI should only be about
>> configuring those services. Whether I want them available or not on
>> certain networks is a function of my relative trust of the network I'm
>> connected to, and hence that's a heuristically automagically managed
>> firewalld thing. So I'd actually pull out the Networks UI out of each
>> of these rather than add it to Remote Login. I don't want to see such
>> configuration choices in two UIs.
>
> The Workstation WG people here seem to prefer the other way - this over
> configuring the relative trust per-network. Someone correct me if I'm
> wrong. :)

How does that work with multihoming? Does the Sharing Panels' Networks
section configures firewalld? I thought it was merely a systemd
service toggle. If so, and I want a service enabled for network A but
not network B, that's a firewall thing.

But also, the user doesn't think this granularly about services
anyway. Their competency is fairly limited to a clunky UI method of
literally asking them what kind of network they're on or their
relative risk assessment of it. And that's until there's a service
that evaluates the volatility of a network dynamically, like fail2ban
on steroids.

The granular approach for services risks is really the exclusive
domain of security experts. So I just don't care for this UI asking me
what networks a service should work on, it's asking me something
outside of my competency.

But there also isn't a replacement for firewall-config yet either.



-- 
Chris Murphy