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

[Stefan Schröder <stefan@xxxxxxxxxxx>]

> Lennart Poettering <lennart@xxxxxxxxxxxxxx> hat am 16.02.2022 13:27 geschrieben:
> Do they? What dos "secure" mean? If there's a security vulnerability,
> maybe talk to the distro about that? They should be interested...

I am not talking about vulnerabilities here. All the major distros maintain hardening guides.
Here an incomplete list:

https://access.redhat.com/security/
https://www.suse.com/documentation/sles11/book_hardening/data/book_hardening.html
https://wiki.archlinux.org/index.php/security
http://www.linuxfromscratch.org/hlfs/
https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html

There are reasons why the distros do not just set all the default settings to the values that are considered "more" secure.

I am well aware that there is no such thing as secure, that's why I had put it in quotes.
But I think that the existence of all these hardening guides is the symptom of a problem.
There are reasons why the package maintainers and distros decide not to ship with 'hardened' defaults.

> If security was as easy as just turning on a boolean, then why would
> anyone want to set that to false?

I am also fully aware that security cannot be just turned on. But I observe that in some domains (let's call them critical infrastructure) would gladly opt for _more_ secure defaults than the 'default' defaults.
 
> If the default settings are too low, why nor raise them for everyone?

I don't know what the specific reasons for package maintainers and integrators are to NOT select secure defaults.
I can just state as a fact that they don't, else all those hardening guides would be superfluous.
 
> 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*. 

Yes, that'd be nice, but I don't think it's realistic. Having an opt-in via the proposed mechanism, it would be much easier to suggest alternative 'hardenend' configurations upstream if they didn't mess up the old defaults.

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

Sure, I could add this in my little world, but I was hoping that through the adoption as a 'standard' it would help the broader effort of making the world a more secure place.

Agreed, this approach is less desirable than just rolling out the 'secure' settings for everyone. But I don't think that's realistic. If Log4J had had an alternative secure configuration that admins could have selected...
It's about the trajectory. I feel that package maintainers would be reluctant to switch their defaults by following the hardening recommendations. But including in their package an alternative 'hardenend' config has a very low barrier to entry.

Best
Stefan Schroeder
Braunschweig/Hannover