[systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG

[Mantas Mikulėnas]

On Wed, Feb 16, 2022 at 2:27 PM Lennart Poettering <lennart at poettering.net>
wrote:

> On Di, 15.02.22 19:05, Stefan Schröder (stefan at tokonoma.de) wrote:
>
> > Situation:
> >
> > Many packages in a distribution ship with a default configuration
> > that is not considered 'secure'.
>
> Do they? What dos "secure" mean? If there's a security vulnerability,
> maybe talk to the distro about that? They should be interested...
>
> > Hardening guidelines are available for all major distributions. Each is
> a little different.
> > Many configuration suggestions are common-sense among security-conscious
> administrators, who have to apply more secure configuration using some
> automation framework after installation.
> >
> > PROPOSAL
> >
> > os-release or machine-info should be amended with a field
> >
> >   PREFER_HARDENED_CONFIG
> >
> > If the value is '1' or 'True' or 'yes' a package manager can opt to
> > configure an alternative, more secure default configuration (if
> > avaialble).
>
> I am not sure what "hardening" means, sounds awfully vague to me. I
> mean, i'd assume that a well meaning distro would lock everything down
> as much as they can *by*default*, except if this comes at too high a
> price on performance or maintainance or so. But how is a single
> boolean going to address that?
>
> If security was as easy as just turning on a boolean, then why would
> anyone want to set that to false?
>
> > According to the 'Securing Debian Manual' [1] the login configuration is
> configured as
> >     auth       optional   pam_faildelay.so  delay=3000000
> > whereas
> >     delay=10000000
> > would provide a more secure default.
> >
> > The package 'login' contains the file /etc/pam.d/login. If dpkg (or
> > apt or rpm or pacman or whatever) detected that os-release asks for
> > secure defaults, the alternative /etc/pam.d./login.harden could be
> > made the default. (This file doesn't exist yet, the details are left
> > to the packaging infrastructure or package maintainer.)
>
> If the default settings are too low, why nor raise them for everyone?
>
> I must say, I am very sure that the primar focus should always be on
> locking things down as well as we can for *everyone* and as
> *default*. Making security an opt-in sounds like a systematically
> wrong approach. If specific security tech cannot be enabled by
> default, then work should be done to make it something that can be
> enabled by default. And if that's not possible then it apparently
> comes at some price, but a simple config boolean somewhere can't
> decide whether that price is worth it...


IMO "locking things down by default" is already overdone a bit...

Arch now ships pam_faillock in its /etc/pam.d/login, and the upstream PAM
default is to lock you out after three consecutive password failures.
*Three.* I'd say that's too high for local console logins even on servers,
but even if it's right for servers it is *way* too strict for personal
machines (e.g. even iPhones allow five wrong PINs).

Especially with GNOME still having a broken keyboard layout indicator
that's stuck permanently on "en", so half the time I resume the laptop and
get three failures for free just because the keyboard is different. You're
in a hurry to check on some problem, make three typos, you're locked out
for 10 minutes, and you're about to throw the computer out the window :-|

I don't think it's a good idea to stick a "lockdown" knob in machine-info,
though (and definitely not os-release) – most admins who want it probably
won't be satisfied with what it does anyway, they'll want their specific
parameters anyway. And in this particular example, maybe the parameters
should be different for *local vs network* logins, rather than depending on
machine type... (I mean, if a machine deserves "hardened" settings, it's
going to be in a locked room and you can't just walk up to it and start
trying passwords anyway.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220217/e7317ee2/attachment.htm>