Yves-Alexis Perez <[email protected]> writes: > Hi Aaron, thanks for the bug report. Note that
Thanks for the quick response, and for considering this request. FTR, it looks like upower makes a stronger justification after all, at least according to popcon, which puts its installation rate at around 48%, vs. 16% for uuid-runtime and a fraction of a percent for the handful of other packages with PrivateUsers=yes hits on codesearch.debian.net. (The 100% installed libuuid1's recommendation evidently doesn't carry as much weight as I'd anticipated -- I suppose installation ignores recommendations, and upgrades tend to preserve the status quo for existing recommendations.) > kernel.unprivileged_userns_clone is already set to 0 by default so it's not > really needed here. Hence "explicitly", for the sake of anyone running a custom kernel that accidentally wound up with a lax default. > I'm not a fan of lifting the max_user_namespace restriction here since it's > there as runtime hardening. I can understand the pain with PrivateUsers but I > still don't think exposing root-designed kernel code to unprivileged users is > a good idea. Sure, and I don't advocate for lifting unprivileged_userns_clone, but AFAICT allowing root to create user namespaces doesn't raise nearly so many concerns, and can even help security insofar as it allows for better isolation. > hardening-runtime is not installed by default so admins installing it are > supposed to understand what they do. They can also locally override the > restriction if needed (for example set it to 1 or 2). Fair enough, and I may go this route. It's perhaps unfortunate that there's no clean way to keep the default setting of this limit alongside 10-hardening.conf's other settings, but the default looks like massive overkill anyway, so I suppose that's no great loss. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[email protected]
