<div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Feb 16, 2022 at 2:27 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Di, 15.02.22 19:05, Stefan Schröder (<a href="mailto:stefan@tokonoma.de" target="_blank">stefan@tokonoma.de</a>) wrote:<br>
<br>
> Situation:<br>
><br>
> Many packages in a distribution ship with a default configuration<br>
> that is not considered 'secure'.<br>
<br>
Do they? What dos "secure" mean? If there's a security vulnerability,<br>
maybe talk to the distro about that? They should be interested...<br>
<br>
> Hardening guidelines are available for all major distributions. Each is a little different.<br>
> Many configuration suggestions are common-sense among security-conscious administrators, who have to apply more secure configuration using some automation framework after installation.<br>
><br>
> PROPOSAL<br>
><br>
> os-release or machine-info should be amended with a field<br>
><br>
>   PREFER_HARDENED_CONFIG<br>
><br>
> If the value is '1' or 'True' or 'yes' a package manager can opt to<br>
> configure an alternative, more secure default configuration (if<br>
> avaialble).<br>
<br>
I am not sure what "hardening" means, sounds awfully vague to me. I<br>
mean, i'd assume that a well meaning distro would lock everything down<br>
as much as they can *by*default*, except if this comes at too high a<br>
price on performance or maintainance or so. But how is a single<br>
boolean going to address that?<br>
<br>
If security was as easy as just turning on a boolean, then why would<br>
anyone want to set that to false?<br>
<br>
> According to the 'Securing Debian Manual' [1] the login configuration is configured as<br>
>     auth       optional   pam_faildelay.so  delay=3000000<br>
> whereas<br>
>     delay=10000000<br>
> would provide a more secure default.<br>
><br>
> The package 'login' contains the file /etc/pam.d/login. If dpkg (or<br>
> apt or rpm or pacman or whatever) detected that os-release asks for<br>
> secure defaults, the alternative /etc/pam.d./login.harden could be<br>
> made the default. (This file doesn't exist yet, the details are left<br>
> to the packaging infrastructure or package maintainer.)<br>
<br>
If the default settings are too low, why nor raise them for everyone?<br>
<br>
I must say, I am very sure that the primar focus should always be on<br>
locking things down as well as we can for *everyone* and as<br>
*default*. Making security an opt-in sounds like a systematically<br>
wrong approach. If specific security tech cannot be enabled by<br>
default, then work should be done to make it something that can be<br>
enabled by default. And if that's not possible then it apparently<br>
comes at some price, but a simple config boolean somewhere can't<br>
decide whether that price is worth it...</blockquote><div><br></div><div>IMO "locking things down by default" is already overdone a bit...</div><div><br></div><div>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. <b>Three.</b> 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).</div><div><br></div><div>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 :-|</div><div><br></div><div>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 <i>local vs network</i> 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.)</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div></div>