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

[Lennart Poettering]

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...

So, quite frnakly, I am not convinced this is desirable.

That said, You can extend machine-info with anything you like, it's
supposed to be extensible. But please make sure you prefix the
variables with some prefix that makes collisions unlikely.

Lennart

--
Lennart Poettering, Berlin