> Lennart Poettering <lenn...@poettering.net> 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
