[arch-general] user namespaces

[sivmu]

Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
>>> it's a nearly useless feature. 
>>
>> That's a baseless claim, that was already proved wrong in my first
>> post
>> by the many applications that use this feature.
> 
> That doesn't demonstrate that it's useful relative to the alternatives.
> It enables unprivileged OS containers but isn't really any use for app
> containers.
> 

Pretty much all famous container programms use this. I wonder why if
there is no use for it.

Also I would still like to see a simple alternative for unprivileged
namespaces to sandbox apps.
How do you provide something like bubblewrap without user namespaces?
And no that android example below is not the same as long as there is no
simple way to use this (which I am not aware of)


>>> but no one really wants it for that reason. They
>>> want it because it started pretending that it can offer something
>>> that
>>> it can't actually deliver safely.
>>
>> Again a claim without prove
> 
> The proof is easy to find. You're the one making a proposal but you
> clearly haven't done your research. It's not my job to spoon feed you.
> 

I do know some of the discussions about this feature on the kernel
mailing list. But the opinions even there are not as clear as you want
to make us believe.


>>> There are much better ways to do
>>> unprivileged sandboxes with significantly less risk than
>>> CLONE_NEWUSER
>>> or setuid executables where the user controls the environment.
>>
>> And yet you fail to name even one alternative. Please do
> 
> Uh, yeah, I did. M
> 

Sorry but 'M' ? I don't get it.

>>> Anything
>>> depending on this mechanism instead of properly designed plumbing
>>> for it
>>> is simply lazy garbage.
>>
>> Another baseless and arrogant claim
> 
> Not baseless and it's not arrogant to point out that this is a bad
> feature for app containers. It's the truth.

even if that is correct, it is a pretty weird/funny argument to say it's
the truth ... :)


>>> There's still an unrelenting torrent of security issues from it. 
>>
>> Name one
> 
> Look at the discussion on the issue report or do basic research on the
> topic. It's your proposal, if you haven't done even basic research
> that's your problem.

I did, but we differ about the interpretations (see below)


> 
>>> Maybe wait until that stops before proposing this. 
>>
>> Vulnerabilities in kernel features will never stop to exist. If we
>> disable everything with potential vulnerabilities, we did not have a
>> kernel anymore.
> 
> It's a very niche feature with better alternatives for sandboxes and app
> containers. It exposes all of the netfilter administration code and tons
> of other networking and mount code as new attack surface.

Point taken


>>
>> Android uses minijail (default app sandbox in android 7), which relies
>> on user namespaces…
>> Just opened a terminal on my android and checked it. Its inside a user
>> namespaces.
> 
> No, that's incorrect and you're just further demonstrating how far out
> of your depth you are here. Google doesn't even enable user namespaces
> in the kernel in AOSP / stock Android for Nexus/Pixel. Doubt that any
> other vendors are enabling it. It doesn't use any namespaces other than
> mount namespaces as part of the multi-user emulation for backwards
> compatibility. It certainly doesn't use minijail as the 'default app
> sandbox'. It uses minijail as a library to factor out common patterns
> involved in privilege dropping, like dropping capabilities. The app
> sandbox is done with uid/gid pairs (AIDs) and the full system SELinux
> policy (untrusted_app domain for regular non-platform apps and
> isolated_app for isolatedProcess services). Permissions are generally
> done with IPC checks but some are done with secondary groups. Before it
> had SELinux, it was just using the POSIX user/group/permission model to
> implement the app sandbox and that's still the base. It has no use case
> at all for user namespaces, and process namespaces would not really have
> much use either due to hidepid=2 since 7.x combined with uid isolation.
> It would just be a mess since they turn a process into a subreaper /
> secondary init.
> 
> Trying to explain to me how Android works from skimming and
> misinterpreting news / documentation and making incorrect assumptions is
> not going to get you far.
> 

Considering what you do for a living I believe you here.

However that also means that A LOT of documentation about how chromium,
android and minijail work is completely wrong. Which is kinda disturbing...


>>>
>>
>> Again no real life example for an alternative
> 
> Android, which was given as an example. You are going out of the way to
> ignore all of the information that's right in front of you.
> 

I am talking about alternatives that provide the same funktionality as
the full set of namespaces like bubblewrap does.



>>  I can point to 30+ kernel bugs from the
>>> past couple years that are privesc via user namespaces. Also those
>>> kernel vulnerabilities impact *everyone*.
>>>
>>
>> Please do point out some from the last 6 mounth.
> 
> CVE-2016-8655 is a simple one that comes to mind. Not accessible attack
> surface to unprivileged users without user namespaces. There are a bunch
> more though!
> 

Now I get this.
Your risk assessment includes all vulnerabilities in all parts of the
kernel that are available to unprivileged users because of user
namespaces. That does make sense but:

There are A LOT of features that provide simular access to these kernel
parts and would make those volnerabilities exploitable for normal users.
That's why I do not share this assessment, although I have to admit that
the provided attack surface of userns is by itself way larger then by
using other vectors.

There was an interesting presentations somewhere that talked about this,
but I cannot find it right now, so I concede this point for now and
agree to your assessment of the risks involved



>>
>> Solutions to change user namespaces inside the kernel? This isn’t the
>> kernel mailing list and arch won’t patch the kernel, so I do not get
>> what you are proposing.
> 
> The kernel change that's required is already upstream
> 

Please provide a link, I would very much like to see this but could not
find it so far.


>>
>> The people responsible for linux distributions like debian, red hat
>> and
>> pretty much all other distros, as well as many developers of
>> sandboxing
>> applications including the tails and chromium people all believe this
>> feature is a useful tool to provide unprivileged sandbox applications
>> worth the risk.
> 
> I haven't seen any such assessment by them about the risk vs. reward and
> comparing it to alternative solutions from a security perspective. The
> Chromium change has a lot more to do with them only really caring about
> ChromeOS (where they can disable userns everywhere but the spawning
> process) and Android (where it's not needed due to a better alternative
> and user namespaces aren't available).
> 
> An argument from authority is worth nothing particularly when those
> people are not actually saying what you claim they are, and here is
> someone that works full time on infosec that's telling you otherwise.
> 

You are right there is no assessment of these people I can point to, but
that was not what I was trying to say anyway.

The point is:
All those distros, everyone except arch has decided at some point to no
longer restrict the use of unprivileged user namespaces. That's the
result we have today, that cannot be denied.

So by enableing this feature I do see a decision that involves the
risks. You can of course claim they do not know what they are doing but
I think that would be pretty arogant to do.

In any case: arch is the last distribution to disable this feature and I
doubt this will go away anytime soon, plus more programms will rely on it.

So even assuming that I am in no position to assess the risks involved,
I think it would be obvious to question this decision when everyone else
seems to think otherwise. Not that majorities are anything to go by but
the maintainers of other distros are not stupid either...