Russ Allbery <r...@debian.org> writes: > "Trent W. Buck" <trentb...@gmail.com> writes: > >> As someone who does that kind of thing a lot, I'd rather have >> the increased annoyance of opt-out hardening than >> the reduced security of opt-in hardening. >> Even if it means I occasionally need to patch site-local rules into >> /etc/apparmor.d/local/usr.bin.msmtp or >> /etc/systemd/system/libvirtd.service.d/override.conf. > > I also feel this way but there are a bunch of people who really, really > don't, and also it's not entirely obvious when hardening is failing or > what overrides you need to add. So making this the default is hard, > because it fundamentally breaks the "it has to work out of the box" > property that people expect. Making it be semi-normal for daemons to not > work out of the box depending on what configuration options or other > packages you have installed is a hard sell.
I agree; that is reasonable. > That makes me want some way to opt in to "hardening that might break > something," but I'm not sure the best way to do that. I think for me the important point is whether "might break something" means a chance of in 1 in one hundred, or 1 in one crore. e.g. I expect "SystemCallArchitectures=native" to break for a lot of people (anyone doing dpkg --add-architecture) e.g. I expect "ProtectClock=yes" to break for very few people, because it's really unlikely that any libnss-foo.so or libpam-foo.so is going to try to change the hardware clock. (Although ProtectClock= requires NoNewPrivileges which is a whole separate kettle of fish, as discussed elsewhere in this thread.)
