linux-kernel - Re: [PATCH 1/3] capabilities: user namespace capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 18 May 2024 18:33:37 -0700
From: Jonathan Calmels <jcalmels@...0.net>
To: John Johansen <john.johansen@...onical.com>
Cc: brauner@...nel.org, ebiederm@...ssion.com, 
	Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <keescook@...omium.org>, 
	Joel Granados <j.granados@...sung.com>, Serge Hallyn <serge@...lyn.com>, 
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, 
	David Howells <dhowells@...hat.com>, Jarkko Sakkinen <jarkko@...nel.org>, containers@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org
Subject: Re: [PATCH 1/3] capabilities: user namespace capabilities

On Sat, May 18, 2024 at 05:27:27AM GMT, John Johansen wrote:
> On 5/17/24 20:50, Jonathan Calmels wrote:
> > As mentioned above, userspace doesn't necessarily have to change. I'm
> > also not sure what you mean by easy to by-pass? If I mask off some
> > capabilities system wide or in a given process tree, I know for a fact
> > that no namespace will ever get those capabilities.
> 
> so by-pass will very much depend on the system but from a distro pov
> we pretty much have to have bwrap enabled if users want to use flatpaks
> (and they do), same story for several other tools. Since this basically
> means said tools need to be available by default, most systems the
> distro is installed on are vulnerable by default. The trivial by-pass
> then becomes the exploit running its payload through one of these tools,
> and yes I have tested it.
> 
> Could a distro disable these tools by default, and require the user/admin
> to enable them, yes though there would be a lot of friction, push back,
> and in the end most systems would still end up with them enabled.
> 
> With the capibilities approach can a user/admin make their system
> more secure than the current situation, absolutely.
> 
> Note, that regardless of what happens with patch 1, and 2. I think we
> either need the big sysctl toggle, or a version of your patch 3

Ah ok, I get you concerns. Unfortunately, I can't really speak for
distros or tooling about how this gets leveraged.
I've never claimed this was going to be bulletproof day 1.
All I'm saying is that they now have the option to do so.

As you pointed out, we're coming from a model where today it's open-bar.
Only now they can put a bouncer in front of it, so to speak :)

Regarding distros:

    Maybe they ship with an empty userns mask by default and admins have
    to tweak it, understanding full well the consequences of doing so.

    Maybe they ship with a conservative mask and use pam rules to
    adjust it.

    Maybe they introduce something like a wheel/sudo group that you need
    to be part of to gain extra privileges in your userns.

    Maybe only some system services (e.g. dockerd, lxd/incusd, machined)
    get confined.

    Maybe they need highly specific policies, and this is where you'll
    would want LSM support. Say an Apparmor profile targetting
    unshare(1) specifically.

Regarding tools:

    Maybe bwrap has its own group you need to be part of to get full
    caps.

    Maybe docker uses this set behind `--cap-add` `--cap-drop`.

    Maybe lxd/incusd imlement ACL restricting who can do what.

    Maybe steam always drops everything it doesn't need,

I'm sure this won't cover every single corner cases, but as stated in
the headline, this is a start, a simple framework we can always
extend if needed in the future.