Let me list the counter arguments to the proposal (to include a new field PREFER_HARDENED_CONFIG) so far:
* The packages should be deploying a secure configuration by default. Counter-argument: Yes, but they don't. There are obviuosly competing interests and sometimes convenience wins. Nonetheless package maintainers would probably appreciate the option to provide a hardened configuration. * System administrators should you use automated tools to configure their systems securely. Counter-argument: Yes, they should. But imagine that your puppet/chef/ansible recipes would become 75% superfluous because the packages are installed using the secure default and your remaining recipes can deal with your real system idiosyncracies instead of boilerplate hardening. * There is no one-size fits all and I don't want to harden my system anyway. Counter-argument: This is not about individual user's needs. It's about large-scale critical infrastructure setups that have hardening requirements galore. And this is about upstream. Solve problems at the root at install time. As has been pointed out in one post "Systemd is about Managing systems after installation increases complexity and adds state and configuration management issues. * "you're going to need tools to manage *that* anyway. Then why not use the same tool(s) to simply manage the machines?" Counter-argument: There is nothing to "manage". You just deploy a hardenend config instead of the default one. It's fire and forget. The work-load to achieve the hardening is distributed across all package maintainers who can opt-in to provide a more secure configuration if they like. While the availability of a hardened configuration is the responsiblity of the package, the implementation of how the secure configuration is copied is the responsibility of the package-manager-developers, who can implement this field at their own pace. There will be probably competition across linux distributions who manages secure configurations best. Right now, there is no support for hardening a system. All the tools and hardening guidelines are adhoc and difficult to maintain while the distributions evolve. It'd be an easy way out for package creators and maintainers that want to offer more secure defaults, but cannot because it might break compatibility and convenience expectations. PS. I concur that os-release is not the right spot for the suggested new field. But machine-info still looks viable to me. yours Stefan
