On Wed, 2020-04-15 at 08:32 +0100, Simon McVittie wrote: > On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote: > > I think you've made a good case that user namespaces are likely to be a > > net positive for security on Debian desktop systems. > > > > This might not be true yet for servers that aren't container hosts. > > Perhaps Debian's kernel should continue to disable unprivileged creation > of user namespaces for now, but we should have a package that installs > a /etc/sysctl.d/*.conf fragment that will enable them, and packages > that benefit from them (bubblewrap, web browsers, sbuild) should have > a Depends or Recommends on that package instead of shipping a setuid-root > namespace-creation helper? [...]
But if users install, say, Chrome or Docker from upstream, it won't know how to do this Debian magic. Also, I don't think we should keep patching in kernel.unprivileged_userns_clone forever, so the documented way to disable user namespaces should be setting user.max_user_namespaces to 0. But then there's no good way to have a drop-in file that changes back to the upstream default, because that's dependent on system memory size. So I think we should do something like this: * Document user.max_user_namespaces in procps's shipped /etc/sysctl.conf * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate it (log a warning if it's changed) * Document the change in bullseye release notes Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way.
signature.asc
Description: This is a digitally signed message part
