Re: [systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
On Wed, Feb 16, 2022 at 2:27 PM Lennart Poettering wrote: > On Di, 15.02.22 19:05, Stefan Schröder (ste...@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=300 > > whereas > > delay=1000 > > 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... IMO "locking things down by default" is already overdone a bit... Arch now ships pam_faillock in its /etc/pam.d/login, and the upstream PAM default is to lock you out after three consecutive password failures. *Three.* I'd say that's too high for local console logins even on servers, but even if it's right for servers it is *way* too strict for personal machines (e.g. even iPhones allow five wrong PINs). Especially with GNOME still having a broken keyboard layout indicator that's stuck permanently on "en", so half the time I resume the laptop and get three failures for free just because the keyboard is different. You're in a hurry to check on some problem, make three typos, you're locked out for 10 minutes, and you're about to throw the computer out the window :-| I don't think it's a good idea to stick a "lockdown" knob in machine-info, though (and definitely not os-release) – most admins who want it probably won't be satisfied with what it does anyway, they'll want their specific parameters anyway. And in this particular example, maybe the parameters should be different for *local vs network* logins, rather than depending on machine type... (I mean, if a machine deserves "hardened" settings, it's going to be in a locked room and you can't just walk up to it and start trying passwords anyway.) -- Mantas Mikulėnas
Re: [systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
On 16/02/2022 17:11, Stefan Schröder wrote: 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. I'm having loads of trouble at work at present - everything is locked down tight because of GDPR and £Millions in fines if things go wrong. There's no way I'm going to lock my home system down like that. What's the saying - the securest system is locked in a safe with no connectivity (and totally unusable :-). There is a very strong trade-off between "secure" and "usable", and different people have different tolerances for friction. For me, passwd/shadow is more than secure enough - learning pam is too much effort/hassle for too little gain. For work, it's LDAP/2FA - mistakes and breaches are costly. All that's being asked for here is some way of telling the system where on the usable/secure spectrum the computer should be configured. As I'm fond of saying, one size does NOT fit all ... Cheers, Wol
Re: [systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
> Lennart Poettering 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
Re: [systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
On Di, 15.02.22 19:05, Stefan Schröder (ste...@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=300 > whereas > delay=1000 > 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
[systemd-devel] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
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=300 whereas delay=1000 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
