Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG

[Stefan Schröder <stefan@xxxxxxxxxxx>]

Situation: 

Many packages in a distribution ship with a default configuration that is not considered 'secure'.

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

E.g. 

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

The existence of PREFER_HARDENED_CONFIG=1 would allow any distribution to select a more suitable default for use-cases where security is considered more important than convenience.

During initial installation of a distribution, the installation tool could ask how to set this value.
Subsequent package installation could then benefit from the more secure defaults.

PRO:

- allows more secure defaults by default
- hardening solved upstream making plethora of distribution specific hardening guides redundant
- contribution to defense-in-depth
- does not impose any particular security policy
- allows smooth transition towards more secure settings

CON:
- yet another entry for os-release

Alternatives considered:
- We could just keep on performing just as badly as before.

[1] https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#id-1.5.14.11] 

Best
Stefan Schroeder