[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 May 2023 13:01:57 +1000
From: David Leadbeater <dgl@....cx>
To: oss-security@...ts.openwall.com
Cc: Turritopsis Dohrnii Teo En Ming <tdtemccnp@...il.com>, ceo@...-en-ming-corp.com,
Piotr Krysiuk <piotras@...il.com>
Subject: Re: New Linux kernel NetFilter flaw gives attackers
root privileges
On Thu, 11 May 2023 at 08:08, Tobias Heider <tobias.heider@...onical.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=
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
