Re: New Linux kernel NetFilter flaw gives attackers root privileges

[David Leadbeater <dgl () dgl cx>]

On Thu, 11 May 2023 at 08:08, Tobias Heider <tobias.heider () canonical com> wrote:
[...]
> This would allow having opt-in unprivileged userns support only for confined and
> explicitly permitted applications and could hopefully drastically reduce the
> impact of similar bugs in the future.

While I think more explicit configurability is good and needed here,
it's possible to selectively block user namespaces by blocking
unshare/clone/setns via seccomp policies. For example Docker's default
policy[1] blocks unshare() and certain arguments to clone().

This is also configurable in systemd through the "RestrictNamespaces"
property on a service. The downside is this is per service, for
example setting "RestrictNamespaces=true" on sshd.service, but then a
user could run an exploit via say cron, so you'd have to audit all
your services for this to be a complete mitigation.

It's also worth pointing out user namespaces can be a powerful
security feature, again with systemd (using systemd-run for
demonstration purposes, I'd expect this to be an actual unit
configuration in production use):

sudo systemd-run -t -p PrivateUsers=true -p RestrictNamespaces=true -p
DynamicUser=true /bin/bash

Will give you a shell inside a user namespace providing some isolation
(see the docs for PrivateUsers[2]), but it restricts "unshare -Ur"
because of the RestrictNamespaces:

unshare: unshare failed: Operation not permitted

As this and other bugs have shown CAP_NET_ADMIN inside a user
namespace is a large attack surface, but an unprivileged user inside a
user namespace, without the ability to create further namespaces can
actually be a worthwhile hardening.

David

[1]: https://github.com/moby/moby/blob/master/profiles/seccomp/default.json#L626-L632
[2]: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateUsers=