Quantcast

user namespaces

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

user namespaces

sivmu
Summary:

Arch Linux is one of the few, if not the only distribution that still
disables or restricts the use of unprivileged user namespaces, a feature
that is used by many applications and containers to provide secure
sandboxing.
There have been request to turn this feature on since Linux 3.13 (in
2013) but they are still being denied. While there may have been some
reason for doing so a few year ago, leading to many distributions like
Debian and Red Hat to restrict its use to privileged users via a kernel
patch (they never disabled it completely), today arch seems to be the
only distribution to block this feature. Even conservative distros like
Debian 8 and 9 have this feature fully enabled.

I would like to suggest that arch stops to disable this feature in
future kernel versions.


Resoning:

The original reason to block user namespaces were a number of security
issues that allowed unprivileged users to access features they should
not have access to. Due to the nature of user namespaces to provide
isolated user environments with access to privileged features like other
namespaces (inside that isolated namespace only), it should be obvious
that this feature had to be designed carefully in order not to harm the
security outside the namespace. Even though there have been issues, this
feature is now considered stable enough for distros like debian and red
hat to allow its use even for unprivileged users.

Moreover there are many applications that use this feature to provide or
enhance security
Among them are:

lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
chromium

After working with sandboxing applications for several month, it seems
clear to me that disabling user namespaces decreases the security of the
system significantly. Some of these applications can not provide core
features due to user namespaces missing. Others have significant
security features disabled for this reasons. But the worst part is how
some of these projects dealt with the missing feature: Many are using
suid bits to execute the application as root to get access to the
features they would have inside a user namespace. And for those who have
worked with suid applications and their security it will not be
surprising that they have failed to do this securely, leading to not
just a few local root exploits.

Taking firejail just as an example:
(CVE-2017-5207)
(CVE-2017-5206)
(CVE-2017-5180)
(CVE-2016-10122)
(CVE-2016-10118)
(CVE-2016-9016)

And that is just from the last release...

non of these issues would have been possible if user namespaces could be
used, which is btw. what bubblewrap does if the feature is available,
but since it isn’t on arch they have to use suid too (but bubblewrap is
designed with security in mind for a change, so no known issues so far)
Chromium is another case that has to use suid to use its sandbox and
while I consider the developers very skilled in regards to security
(they build a very nice broker architecture sandbox on windows too)
there have been local root exploits in the linux version of chromium
because of this.


Even while looking at the surface of this problem it becomes clear this
causes way more problems then it solves. Considering arch will be or
already is the only linux distribution to disable this feature,
developers of future applications will have to chose between dropping
support for arch or to keep using features like suid that pose a real
security threat opposite to user namespaces.

Therefore I urge the people responsible to reconsider their choice an
enable user namespaces in future kernel versions of arch linux.


Bug reports regarding user namespaces:

https://bugs.archlinux.org/task/36969
https://bugs.archlinux.org/task/49337


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:

> Summary:
>
> Arch Linux is one of the few, if not the only distribution that still
> disables or restricts the use of unprivileged user namespaces, a
> feature
> that is used by many applications and containers to provide secure
> sandboxing.
> There have been request to turn this feature on since Linux 3.13 (in
> 2013) but they are still being denied. While there may have been some
> reason for doing so a few year ago, leading to many distributions like
> Debian and Red Hat to restrict its use to privileged users via a
> kernel
> patch (they never disabled it completely), today arch seems to be the
> only distribution to block this feature. Even conservative distros
> like
> Debian 8 and 9 have this feature fully enabled.
There are still endless unprivileged user namespace vulnerabilities and
it's a nearly useless feature. The uid/gid mapping is poorly thought out
and immature without the necessary environment (filesystem support,
etc.) built around it, 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. 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. Anything
depending on this mechanism instead of properly designed plumbing for it
is simply lazy garbage. Lack of a proper layer on top of the kernel
providing infrastructure (systemd is so far from that) on desktop/server
Linux is not going to be fixed by delegating everything to the kernel
even when it massively increases attack surface.

> I would like to suggest that arch stops to disable this feature in
> future kernel versions.
>
> Resoning:
>
> The original reason to block user namespaces were a number of security
> issues that allowed unprivileged users to access features they should
> not have access to. Due to the nature of user namespaces to provide
> isolated user environments with access to privileged features like
> other
> namespaces (inside that isolated namespace only), it should be obvious
> that this feature had to be designed carefully in order not to harm
> the
> security outside the namespace. Even though there have been issues,
> this
> feature is now considered stable enough for distros like debian and
> red
> hat to allow its use even for unprivileged users.
There's still an unrelenting torrent of security issues from it. Maybe
wait until that stops before proposing this. I don't think it's going to
stop because of how this feature is designed. It greatly increases the
attack surface and there isn't going to be a mitigating factor that
changes this situation. It's a fundamentally flawed, garbage feature and
 the arguments for it are nonsense. There are better ways to do this, by
simply not tying your hands and refusing to implement anything in user
space but instead pretending that all common features must happen in the
kernel despite major security risks and poor semantics.

> Moreover there are many applications that use this feature to provide
> or
> enhance security
> Among them are:
>
> lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
> chromium

There's one well-written sandbox there (Chromium's usage) and it doesn't
require this feature. They also don't need this feature on platforms
where they have control like Android, since they can implement it in a
saner way where it doesn't massively increase kernel attack surface.

> After working with sandboxing applications for several month, it seems
> clear to me that disabling user namespaces decreases the security of
> the
> system significantly. Some of these applications can not provide core
> features due to user namespaces missing. Others have significant
> security features disabled for this reasons. But the worst part is how
> some of these projects dealt with the missing feature: Many are using
> suid bits to execute the application as root to get access to the
> features they would have inside a user namespace. And for those who
> have
> worked with suid applications and their security it will not be
> surprising that they have failed to do this securely, leading to not
> just a few local root exploits.
There's no hard requirement that they have to do it that way. They can
use a service where the user doesn't control the environment used to
spawn the application (like setuid) or full control over the environment
where it ends up being run. Application containers *really* do not need
this feature. It's far better to do it in a more secure, saner way vs.
exposing massive kernel attack surface.

> Taking firejail just as an example:
> (CVE-2017-5207)
> (CVE-2017-5206)
> (CVE-2017-5180)
> (CVE-2016-10122)
> (CVE-2016-10118)
> (CVE-2016-9016)

A junk, insecure application is not a reason to greatly reduce kernel
security for everyone.

> And that is just from the last release...
>
> non of these issues would have been possible if user namespaces could
> be
> used, which is btw. what bubblewrap does if the feature is available,
> but since it isn’t on arch they have to use suid too (but bubblewrap
> is
> designed with security in mind for a change, so no known issues so
> far)
> Chromium is another case that has to use suid to use its sandbox and
> while I consider the developers very skilled in regards to security
> (they build a very nice broker architecture sandbox on windows too)
> there have been local root exploits in the linux version of chromium
> because of this.
Chromium has had a couple vulnerabilities there. Can you point to any
that are full blown privesc? I can point to 30+ kernel bugs from the
past couple years that are privesc via user namespaces. Also those
kernel vulnerabilities impact *everyone*.

> Even while looking at the surface of this problem it becomes clear
> this
> causes way more problems then it solves. Considering arch will be or
> already is the only linux distribution to disable this feature,
> developers of future applications will have to chose between
> droppingsupport for arch or to keep using features like suid that pose
> a real security threat opposite to user namespaces.

Nope, you're just ignoring / misrepresenting the facts here and failing
to present a real proposal. Try again, and propose something where
attack surface is not increased beyond the cases where this feature is
actually required. Enabling it globally when people install something
like Chromium doesn't qualify.

User namespaces are far more real of a security threat than these fears
you're presenting here, and doing it as you propose would impose those
risks on EVERYONE so that the few can have their poorly designed
container features based on this.

> Therefore I urge the people responsible to reconsider their choice an
> enable user namespaces in future kernel versions of arch linux.

Present a real proposal taking into account the very real reasons to
avoid this that you are skirting around. If you aren't going to present
technical solutions to the problems, which are certainly possible and
could be implemented, then I don't think anything should be changed.

I have thoughts on how to enable this while containing the attack
surface but seeing as I have no interest in the feature and have a lot
of far more important work to do than working on toy features, I don't
plan on doing anything about this myself.

> Bug reports regarding user namespaces:
>
> https://bugs.archlinux.org/task/36969
> https://bugs.archlinux.org/task/49337


signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by sivmu
So, why don't you compile your own kernel?

Using abs and changing the config-file is the only thing you'd have to do.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by arch general mailing list-2
Also worth noting that one of the first thing any sandbox based on user
namespaces will do is *disabling* user namespaces. The programs using
them acknowledge them to be a huge security problem. It doesn't work out
well when only a subset of processes are running in that container env.

The only sane way to approach this without taking a different path is
implementing plumbing to only expose user namespaces to the sandbox
spawning executables. Kernel infrastructure exists for doing that
already. It just depends on whether anyone is willing to do any real
work vs. complaining about it and denying the facts.

signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

Leonid Isaev-3
In reply to this post by arch general mailing list-2
On Wed, Feb 01, 2017 at 01:20:41AM -0500, Daniel Micay via arch-general wrote:

> On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > Summary:
> >
> > Arch Linux is one of the few, if not the only distribution that still
> > disables or restricts the use of unprivileged user namespaces, a
> > feature
> > that is used by many applications and containers to provide secure
> > sandboxing.
> > There have been request to turn this feature on since Linux 3.13 (in
> > 2013) but they are still being denied. While there may have been some
> > reason for doing so a few year ago, leading to many distributions like
> > Debian and Red Hat to restrict its use to privileged users via a
> > kernel
> > patch (they never disabled it completely), today arch seems to be the
> > only distribution to block this feature. Even conservative distros
> > like
> > Debian 8 and 9 have this feature fully enabled.
>
> There are still endless unprivileged user namespace vulnerabilities and
> it's a nearly useless feature. The uid/gid mapping is poorly thought out
> and immature without the necessary environment (filesystem support,
> etc.) built around it, 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. 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. Anything
> depending on this mechanism instead of properly designed plumbing for it
> is simply lazy garbage. Lack of a proper layer on top of the kernel
> providing infrastructure (systemd is so far from that) on desktop/server
> Linux is not going to be fixed by delegating everything to the kernel
> even when it massively increases attack surface.

BTW, why can't one simply create a *privileged* lxc container on a host
filesystem mounted with nosuid, then create an unprivileged user inside that
container for browsing / viewing of untrusted pdfs, etc?

But I still believe that the idea of sandboxing a web browser is idiotic...

Cheers,
--
Leonid Isaev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
On Wed, 2017-02-01 at 00:21 -0700, Leonid Isaev wrote:

> On Wed, Feb 01, 2017 at 01:20:41AM -0500, Daniel Micay via arch-
> general wrote:
> > On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > > Summary:
> > >
> > > Arch Linux is one of the few, if not the only distribution that
> > > still
> > > disables or restricts the use of unprivileged user namespaces, a
> > > feature
> > > that is used by many applications and containers to provide secure
> > > sandboxing.
> > > There have been request to turn this feature on since Linux 3.13
> > > (in
> > > 2013) but they are still being denied. While there may have been
> > > some
> > > reason for doing so a few year ago, leading to many distributions
> > > like
> > > Debian and Red Hat to restrict its use to privileged users via a
> > > kernel
> > > patch (they never disabled it completely), today arch seems to be
> > > the
> > > only distribution to block this feature. Even conservative distros
> > > like
> > > Debian 8 and 9 have this feature fully enabled.
> >
> > There are still endless unprivileged user namespace vulnerabilities
> > and
> > it's a nearly useless feature. The uid/gid mapping is poorly thought
> > out
> > and immature without the necessary environment (filesystem support,
> > etc.) built around it, 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. 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.
> > Anything
> > depending on this mechanism instead of properly designed plumbing
> > for it
> > is simply lazy garbage. Lack of a proper layer on top of the kernel
> > providing infrastructure (systemd is so far from that) on
> > desktop/server
> > Linux is not going to be fixed by delegating everything to the
> > kernel
> > even when it massively increases attack surface.
>
> BTW, why can't one simply create a *privileged* lxc container on a
> host
> filesystem mounted with nosuid, then create an unprivileged user
> inside that
> container for browsing / viewing of untrusted pdfs, etc?
Application containers don't have a use for the user namespace quasi
root and no one really needs the half baked uid/gid mapping feature.
There's no real reason for stuff being done that way beyond desktop
Linux having the disease of inability to do plumbing in userspace, but
instead putting everything in the kernel simply to have it universally
available rather than for technical reasons.

It would make sense to simply have a service spawning on-demand unpriv
users from a range of uid/gid pairs. That's exactly how this works on
Android for both apps and isolatedProcess services (they each get a
unique uid/gid pair assigned), although they also layer SELinux and
mount namespaces on top.

The only real use case for user namespaces is unprivileged, contained
usage of OS containers since they actually need the quasi root. For
application containers / sandboxes, it's just laziness and bad design.

signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

Leonid Isaev-3
On Wed, Feb 01, 2017 at 02:45:46AM -0500, Daniel Micay wrote:

> Application containers don't have a use for the user namespace quasi
> root and no one really needs the half baked uid/gid mapping feature.
> There's no real reason for stuff being done that way beyond desktop
> Linux having the disease of inability to do plumbing in userspace, but
> instead putting everything in the kernel simply to have it universally
> available rather than for technical reasons.
>
> It would make sense to simply have a service spawning on-demand unpriv
> users from a range of uid/gid pairs. That's exactly how this works on
> Android for both apps and isolatedProcess services (they each get a
> unique uid/gid pair assigned), although they also layer SELinux and
> mount namespaces on top.

Cool :) thx for the explanation...

Cheers,
L.

--
Leonid Isaev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

sivmu
In reply to this post by arch general mailing list-2


Am 01.02.2017 um 07:20 schrieb Daniel Micay via arch-general:

> On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
>> Summary:
>>
>> Arch Linux is one of the few, if not the only distribution that still
>> disables or restricts the use of unprivileged user namespaces, a
>> feature
>> that is used by many applications and containers to provide secure
>> sandboxing.
>> There have been request to turn this feature on since Linux 3.13 (in
>> 2013) but they are still being denied. While there may have been some
>> reason for doing so a few year ago, leading to many distributions like
>> Debian and Red Hat to restrict its use to privileged users via a
>> kernel
>> patch (they never disabled it completely), today arch seems to be the
>> only distribution to block this feature. Even conservative distros
>> like
>> Debian 8 and 9 have this feature fully enabled.
>
> There are still endless unprivileged user namespace vulnerabilities

You failed to name even one.


> 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.


> The uid/gid mapping is poorly thought out
> and immature without the necessary environment (filesystem support,
> etc.) built around it,

Something like mount namespaces, that are designed to be used in
combination with user namespaces?

> 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

> 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

> Anything
> depending on this mechanism instead of properly designed plumbing for it
> is simply lazy garbage.

Another baseless and arrogant claim

> Lack of a proper layer on top of the kernel
> providing infrastructure (systemd is so far from that) on desktop/server
> Linux is not going to be fixed by delegating everything to the kernel
> even when it massively increases attack surface.
>
>> I would like to suggest that arch stops to disable this feature in
>> future kernel versions.
>>
>> Resoning:
>>
>> The original reason to block user namespaces were a number of security
>> issues that allowed unprivileged users to access features they should
>> not have access to. Due to the nature of user namespaces to provide
>> isolated user environments with access to privileged features like
>> other
>> namespaces (inside that isolated namespace only), it should be obvious
>> that this feature had to be designed carefully in order not to harm
>> the
>> security outside the namespace. Even though there have been issues,
>> this
>> feature is now considered stable enough for distros like debian and
>> red
>> hat to allow its use even for unprivileged users.
>
> There's still an unrelenting torrent of security issues from it.
Name one

> 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.

> I don't think it's going to
> stop because of how this feature is designed. It greatly increases the
> attack surface and there isn't going to be a mitigating factor that
> changes this situation. It's a fundamentally flawed, garbage feature and
>  the arguments for it are nonsense. There are better ways to do this, by
> simply not tying your hands and refusing to implement anything in user
> space but instead pretending that all common features must happen in the
> kernel despite major security risks and poor semantics.
>

So this is actually about you not liking this feature without naming any
real reason making a bunch of baseless accusations and claims.


>> Moreover there are many applications that use this feature to provide
>> or
>> enhance security
>> Among them are:
>>
>> lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
>> chromium
>
> There's one well-written sandbox there (Chromium's usage) and it doesn't
> require this feature.
Wrong

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md

And for suid:

Quote:
„The intention is if you want to run Chrome and only use the namespace
sandbox, you can set --disable-setuid-sandbox.  But if you do so on a
host without appropriate kernel support for the namespace sandbox,
Chrome will loudly refuse to run.“

Source:
https://bugs.chromium.org/p/chromium/issues/detail?id=598454


They also don't need this feature on platforms
> where they have control like Android, since they can implement it in a
> saner way where it doesn't massively increase kernel attack surface.
>

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.

>> After working with sandboxing applications for several month, it seems
>> clear to me that disabling user namespaces decreases the security of
>> the
>> system significantly. Some of these applications can not provide core
>> features due to user namespaces missing. Others have significant
>> security features disabled for this reasons. But the worst part is how
>> some of these projects dealt with the missing feature: Many are using
>> suid bits to execute the application as root to get access to the
>> features they would have inside a user namespace. And for those who
>> have
>> worked with suid applications and their security it will not be
>> surprising that they have failed to do this securely, leading to not
>> just a few local root exploits.
>
> There's no hard requirement that they have to do it that way. They can
> use a service where the user doesn't control the environment used to
> spawn the application (like setuid) or full control over the environment
> where it ends up being run. Application containers *really* do not need
> this feature. It's far better to do it in a more secure, saner way vs.
> exposing massive kernel attack surface.
>
Again no real life example for an alternative

>> Taking firejail just as an example:
>> (CVE-2017-5207)
>> (CVE-2017-5206)
>> (CVE-2017-5180)
>> (CVE-2016-10122)
>> (CVE-2016-10118)
>> (CVE-2016-9016)
>
> A junk, insecure application is not a reason to greatly reduce kernel
> security for everyone.
>
I actually do not really want to argue with you about this one except
that your claim for reduced kernel security is greatly exaggerated.

And please not that the security of firejail would be grreatly increa

>> And that is just from the last release...
>>
>> non of these issues would have been possible if user namespaces could
>> be
>> used, which is btw. what bubblewrap does if the feature is available,
>> but since it isn’t on arch they have to use suid too (but bubblewrap
>> is
>> designed with security in mind for a change, so no known issues so
>> far)
>> Chromium is another case that has to use suid to use its sandbox and
>> while I consider the developers very skilled in regards to security
>> (they build a very nice broker architecture sandbox on windows too)
>> there have been local root exploits in the linux version of chromium
>> because of this.
>
> Chromium has had a couple vulnerabilities there. Can you point to any
> that are full blown privesc?
Local root exploit in chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=76542

you are welcome

 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.

>> Even while looking at the surface of this problem it becomes clear
>> this
>> causes way more problems then it solves. Considering arch will be or
>> already is the only linux distribution to disable this feature,
>> developers of future applications will have to chose between
>> droppingsupport for arch or to keep using features like suid that pose
>> a real security threat opposite to user namespaces.
>
> Nope, you're just ignoring / misrepresenting the facts here and failing
> to present a real proposal. Try again, and propose something where
> attack surface is not increased beyond the cases where this feature is
> actually required. Enabling it globally when people install something
> like Chromium doesn't qualify.
>
> User namespaces are far more real of a security threat than these fears
> you're presenting here, and doing it as you propose would impose those
> risks on EVERYONE so that the few can have their poorly designed
> container features based on this.
>
I do not share your assessment of the threat posed by userns and you
have given me no reaseon to share your opinion yet

>> Therefore I urge the people responsible to reconsider their choice an
>> enable user namespaces in future kernel versions of arch linux.
>
> Present a real proposal taking into account the very real reasons to
> avoid this that you are skirting around. If you aren't going to present
> technical solutions to the problems, which are certainly possible and
> could be implemented, then I don't think anything should be changed.
>

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.

> I have thoughts on how to enable this while containing the attack
> surface but seeing as I have no interest in the feature and have a lot
> of far more important work to do than working on toy features, I don't
> plan on doing anything about this myself.
>

Please share this either here or via direct mail and I will work on this
as far as I am able.

>> Bug reports regarding user namespaces:
>>
>> https://bugs.archlinux.org/task/36969
>> https://bugs.archlinux.org/task/49337
>


To make this short, please provide sources for your claim regarding the
kernel attack surface of user namespaces and alternatives to provide the
same funktionality.



To conclude:


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.

Without any real prove of the claims you made in your post, it seems you
rather have a personal grudge against this feature while at the same
time saying you know better then all these people.
Sorry but that is pretty rich.

Don’t get me wrong I would love to discuss with you about this all day
long but I would like to ask you to reconsider your tone, as you sound
incredibly arrogant when you put yourself above all those voices/people
without providing real prove for your arguments.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

Leonid Isaev-3
On Wed, Feb 01, 2017 at 07:51:49PM +0100, sivmu wrote:
> 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.

But you see, sandboxing apps is by itself is a misleading security feature. Why
do I need to sandbox my browser if it is written properly and allows me to
disable the unnecessary (for me) features?

In the end, every sandbox uses DAC protection, no? And I already proposed a
sandbox which is far better than firejail or the one used in chrome, and
doesn't use userns.

>
> Without any real prove of the claims you made in your post, it seems you
> rather have a personal grudge against this feature while at the same
> time saying you know better then all these people.
> Sorry but that is pretty rich.

The issue is this: either enable userns fully, i.e. unprivileged users are
able to create user namespaecs, or don't enable them at all. The way Fedora
does things, for example, is worse that the latter (of course, if you used
Fedora you know that it sucks in general).

> Don’t get me wrong I would love to discuss with you about this all day
> long but I would like to ask you to reconsider your tone, as you sound
> incredibly arrogant when you put yourself above all those voices/people
> without providing real prove for your arguments.

So, why don't you just build your own kernel? It takes only 20 mins...

Cheers,
--
Leonid Isaev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by sivmu
On Wed, 2017-02-01 at 19:51 +0100, sivmu wrote:

>
> Am 01.02.2017 um 07:20 schrieb Daniel Micay via arch-general:
> > On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > > Summary:
> > >
> > > Arch Linux is one of the few, if not the only distribution that
> > > still
> > > disables or restricts the use of unprivileged user namespaces, a
> > > feature
> > > that is used by many applications and containers to provide secure
> > > sandboxing.
> > > There have been request to turn this feature on since Linux 3.13
> > > (in
> > > 2013) but they are still being denied. While there may have been
> > > some
> > > reason for doing so a few year ago, leading to many distributions
> > > like
> > > Debian and Red Hat to restrict its use to privileged users via a
> > > kernel
> > > patch (they never disabled it completely), today arch seems to be
> > > the
> > > only distribution to block this feature. Even conservative distros
> > > like
> > > Debian 8 and 9 have this feature fully enabled.
> >
> > There are still endless unprivileged user namespace vulnerabilities
>
>
> You failed to name even one.
I already listed several in the linked issue reports.

> > 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.

> > The uid/gid mapping is poorly thought out
> > and immature without the necessary environment (filesystem support,
> > etc.) built around it, 
>
> Something like mount namespaces, that are designed to be used in
> combination with user namespaces?

That has nothing to do with this.

> > 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.

> > 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

> > 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.

> > Lack of a proper layer on top of the kernel
> > providing infrastructure (systemd is so far from that) on
> > desktop/server
> > Linux is not going to be fixed by delegating everything to the
> > kernel
> > even when it massively increases attack surface.
> >
> > > I would like to suggest that arch stops to disable this feature in
> > > future kernel versions.
> > >
> > > Resoning:
> > >
> > > The original reason to block user namespaces were a number of
> > > security
> > > issues that allowed unprivileged users to access features they
> > > should
> > > not have access to. Due to the nature of user namespaces to
> > > provide
> > > isolated user environments with access to privileged features like
> > > other
> > > namespaces (inside that isolated namespace only), it should be
> > > obvious
> > > that this feature had to be designed carefully in order not to
> > > harm
> > > the
> > > security outside the namespace. Even though there have been
> > > issues,
> > > this
> > > feature is now considered stable enough for distros like debian
> > > and
> > > red
> > > hat to allow its use even for unprivileged users.
> >
> > 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.


> > 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.

> > I don't think it's going to
> > stop because of how this feature is designed. It greatly increases
> > the
> > attack surface and there isn't going to be a mitigating factor that
> > changes this situation. It's a fundamentally flawed, garbage feature
> > and
> >  the arguments for it are nonsense. There are better ways to do
> > this, by
> > simply not tying your hands and refusing to implement anything in
> > user
> > space but instead pretending that all common features must happen in
> > the
> > kernel despite major security risks and poor semantics.
> >
>
> So this is actually about you not liking this feature without naming
> any
> real reason making a bunch of baseless accusations and claims.
There are no baseless claims / accusations here. I am not going to spoon
feed you information that's already in the issue reports, easily found
on oss-security, etc.

> > > Moreover there are many applications that use this feature to
> > > provide
> > > or
> > > enhance security
> > > Among them are:
> > >
> > > lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail,
> > > firefox,
> > > chromium
> >
> > There's one well-written sandbox there (Chromium's usage) and it
> > doesn't
> > require this feature. 
>
> Wrong
>
> https://chromium.googlesource.com/chromium/src/+/master/docs/linux_san
> dboxing.md
>
> And for suid:
>
> Quote:
> „The intention is if you want to run Chrome and only use the namespace
> sandbox, you can set --disable-setuid-sandbox.  But if you do so on a
> host without appropriate kernel support for the namespace sandbox,
> Chrome will loudly refuse to run.“
That switch isn't passed, which should be pretty clear considering that
it runs.

> Source:
> https://bugs.chromium.org/p/chromium/issues/detail?id=598454

That doesn't do what you think it does.

>
>
> They also don't need this feature on platforms
> > where they have control like Android, since they can implement it in
> > a
> > saner way where it doesn't massively increase kernel attack surface.
> >
>
> 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.

> > > After working with sandboxing applications for several month, it
> > > seems
> > > clear to me that disabling user namespaces decreases the security
> > > of
> > > the
> > > system significantly. Some of these applications can not provide
> > > core
> > > features due to user namespaces missing. Others have significant
> > > security features disabled for this reasons. But the worst part is
> > > how
> > > some of these projects dealt with the missing feature: Many are
> > > using
> > > suid bits to execute the application as root to get access to the
> > > features they would have inside a user namespace. And for those
> > > who
> > > have
> > > worked with suid applications and their security it will not be
> > > surprising that they have failed to do this securely, leading to
> > > not
> > > just a few local root exploits.
> >
> > There's no hard requirement that they have to do it that way. They
> > can
> > use a service where the user doesn't control the environment used to
> > spawn the application (like setuid) or full control over the
> > environment
> > where it ends up being run. Application containers *really* do not
> > need
> > this feature. It's far better to do it in a more secure, saner way
> > vs.
> > exposing massive kernel attack surface.
> >
>
> 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.

> > > Taking firejail just as an example:
> > > (CVE-2017-5207)
> > > (CVE-2017-5206)
> > > (CVE-2017-5180)
> > > (CVE-2016-10122)
> > > (CVE-2016-10118)
> > > (CVE-2016-9016)
> >
> > A junk, insecure application is not a reason to greatly reduce
> > kernel
> > security for everyone.
> >
>
> I actually do not really want to argue with you about this one except
> that your claim for reduced kernel security is greatly exaggerated.
Not exaggerated at all. It adds a huge amount of attack surface. It's no
joke to suddenly expect all of netfilter to handle untrusted
administration, and that's just one of a bunch of API surfaces added as
attack surface for unprivileged users.


> And please not that the security of firejail would be grreatly increa
>
> > > And that is just from the last release...
> > >
> > > non of these issues would have been possible if user namespaces
> > > could
> > > be
> > > used, which is btw. what bubblewrap does if the feature is
> > > available,
> > > but since it isn’t on arch they have to use suid too (but
> > > bubblewrap
> > > is
> > > designed with security in mind for a change, so no known issues so
> > > far)
> > > Chromium is another case that has to use suid to use its sandbox
> > > and
> > > while I consider the developers very skilled in regards to
> > > security
> > > (they build a very nice broker architecture sandbox on windows
> > > too)
> > > there have been local root exploits in the linux version of
> > > chromium
> > > because of this.
> >
> > Chromium has had a couple vulnerabilities there. Can you point to
> > any
> > that are full blown privesc?
>
> Local root exploit in chromium:
> https://bugs.chromium.org/p/chromium/issues/detail?id=76542
>
> you are welcome
If you read past the initial information (seems to be a consistent
problem for you), you'll see that they determined that it didn't seem to
really be a privilege escalation bug after all. I was already aware of
that issue, and it's exactly why I asked for a real privilege escalation
bug caused by chrome-sandbox because I am not aware of one.

>  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!

> > > Even while looking at the surface of this problem it becomes clear
> > > this
> > > causes way more problems then it solves. Considering arch will be
> > > or
> > > already is the only linux distribution to disable this feature,
> > > developers of future applications will have to chose between
> > > droppingsupport for arch or to keep using features like suid that
> > > pose
> > > a real security threat opposite to user namespaces.
> >
> > Nope, you're just ignoring / misrepresenting the facts here and
> > failing
> > to present a real proposal. Try again, and propose something where
> > attack surface is not increased beyond the cases where this feature
> > is
> > actually required. Enabling it globally when people install
> > something
> > like Chromium doesn't qualify.
> >
> > User namespaces are far more real of a security threat than these
> > fears
> > you're presenting here, and doing it as you propose would impose
> > those
> > risks on EVERYONE so that the few can have their poorly designed
> > container features based on this.
> >
>
> I do not share your assessment of the threat posed by userns and you
> have given me no reaseon to share your opinion yet
You haven't done any real research, so you're in no position to draw
conclusions.

> > > Therefore I urge the people responsible to reconsider their choice
> > > an
> > > enable user namespaces in future kernel versions of arch linux.
> >
> > Present a real proposal taking into account the very real reasons to
> > avoid this that you are skirting around. If you aren't going to
> > present
> > technical solutions to the problems, which are certainly possible
> > and
> > could be implemented, then I don't think anything should be changed.
> >
>
> 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

> > I have thoughts on how to enable this while containing the attack
> > surface but seeing as I have no interest in the feature and have a
> > lot
> > of far more important work to do than working on toy features, I
> > don't
> > plan on doing anything about this myself.
> >
>
> Please share this either here or via direct mail and I will work on
> this
> as far as I am able.
>
> > > Bug reports regarding user namespaces:
> > >
> > > https://bugs.archlinux.org/task/36969
> > > https://bugs.archlinux.org/task/49337
>
>
> To make this short, please provide sources for your claim regarding
> the
> kernel attack surface of user namespaces and alternatives to provide
> the
> same funktionality.
>
>
>
> To conclude:
>
>
> 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.

> Without any real prove of the claims you made in your post, it seems
> you
> rather have a personal grudge against this feature while at the same
> time saying you know better then all these people.
> Sorry but that is pretty rich.
>
> Don’t get me wrong I would love to discuss with you about this all day
> long but I would like to ask you to reconsider your tone, as you sound
> incredibly arrogant when you put yourself above all those
> voices/people
> without providing real prove for your arguments.
You're the one making a proposal without having done much research into
it, and you're going out of your way to only skim the available info.

Not spoon feeding you information != lack of sources. You're the one
making a proposal about this. It's on you to get yourself up to speed
about the recent bugs exposed as privilege escalation vulns due to user
namespaces. It's easy to find a dozen of them from the past 6 months
simply from basic Google searches / oss-security, but there are many
more if you actually dig deeper into CVEs and bug fixes backported to
stables for these issues without CVEs.

signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
As somebody with no actual knowledge of the details you guys are
arguing over, but it seems to me OP has yet to learn that a simpler
and more secure environment can only be achieved by using fewer and
powerful components instead of many useless ones. Okay, there might be
a point from which the amount of components will add enough obscurity
to the overall system that simply nobody will bother trying to break
it, but really, what's the big deal. I think sandboxing is a concept
reminding too much of windows tools such as bullguard, which simply
doesn't translate well enough (read: at all) to unixes, so I recommend
checking whether you can trust the few things you use instead of
adding a whole bunch of potempkin barriers. It's actually less work
overall, too.

cheers!
mar77i
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

sivmu
In reply to this post by arch general mailing list-2


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...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: sandboxing

sivmu
In reply to this post by Leonid Isaev-3
-- Changed the topic to keep things clean --


Am 01.02.2017 um 21:16 schrieb Leonid Isaev:
>
> But you see, sandboxing apps is by itself is a misleading security feature. Why
> do I need to sandbox my browser if it is written properly and allows me to
> disable the unnecessary (for me) features?
>

Sorry to say this, but this is the most disturbingly naive thing I have
read in quite some time.


As a rule, it is said that programms contain one error for every 1000
lines of code.

Firefox contains 14 million lines of code
Chromium has 15,3 million lines

Do the math


No matter how much you focus on secure coding, there will always be
vulnerabilities and sandboxing can help to contain the consequences of
their exploitation.

However it is to be said, that sandboxing does not protect the contained
application and the data it has access to. Therefore sandboxing a
browser will not prevent the compromisation of the data you access with
it. Sandboxing a browser has therefore only limited use.




> In the end, every sandbox uses DAC protection, no? And I already proposed a
> sandbox which is far better than firejail or the one used in chrome, and
> doesn't use userns.
>

Please take a look at bubblewrap
https://github.com/projectatomic/bubblewrap

On the default arch kernel it does not use user namespaces.

It is also use by tails to sandbox firefox or rather the tor browser


And chromium actually uses quite some nice sandboxing and has become
quite famous for being nearly unbreakable. They also have a bug bounty
programm, so if you find a way to break out of their sandbox you can get
up to 100k. Good luck :)


>>
>> Without any real prove of the claims you made in your post, it seems you
>> rather have a personal grudge against this feature while at the same
>> time saying you know better then all these people.
>> Sorry but that is pretty rich.
>
> The issue is this: either enable userns fully, i.e. unprivileged users are
> able to create user namespaecs, or don't enable them at all. The way Fedora
> does things, for example, is worse that the latter (of course, if you used
> Fedora you know that it sucks in general).
>
grsecurity has user namespaces enabled but restricted to privileged
users only. This allows privileged apps like docker to use this feature.
I think they know what they are doing.

btw. what does fedora do exactly? (I think I found somthing about a
kernel module parameter to enable userns. not sure why that is bad)

>> Don’t get me wrong I would love to discuss with you about this all day
>> long but I would like to ask you to reconsider your tone, as you sound
>> incredibly arrogant when you put yourself above all those voices/people
>> without providing real prove for your arguments.
>
> So, why don't you just build your own kernel? It takes only 20 mins...
>
> Cheers,
>

thats not helping. And this is not about me getting this feature but
about a ton of applications that use suid and other shit to work around
this problem, which creates a lot of security problems for arch only.

And yes as pointed out without using these apps the kernel without
userns might be safer, but this still does not solve the general issue.




Am 01.02.2017 um 22:22 schrieb Martin Kühne via arch-general:
> As somebody with no actual knowledge of the details you guys are
> arguing over, but it seems to me OP has yet to learn that a simpler
> and more secure environment can only be achieved by using fewer and
> powerful components instead of many useless ones.

the features in question are inside the kernel and apart from user
namespaces there is no controvery that these features are helpful to
build containers.

But to provide unprivileged users with the ability to use namespaces,
user namespaces are required.


> Okay, there might be
> a point from which the amount of components will add enough obscurity
> to the overall system that simply nobody will bother trying to break
> it, but really, what's the big deal. I think sandboxing is a concept
> reminding too much of windows tools such as bullguard, which simply
> doesn't translate well enough (read: at all) to unixes, so I recommend
> checking whether you can trust the few things you use instead of
> adding a whole bunch of potempkin barriers. It's actually less work
> overall, too.

Not really sure what your point is here.
Sandboxing is not a concept from windows and that bullguard looks like
garbage after 0.1 seconds of looking at is, so no that does not compare.

Sandboxing has many aspects and is not bount to any plattform.

It should be said though, that sandboxing is not a replacement for
secure coding and has its limits.




signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by sivmu
>
> All those distros, everyone except arch has decided at some point to no
> longer restrict the use of unprivileged user namespaces.
>

In no way whatsoever does Arch restrict the use of unprivileged user
namespaces. Rebuilding your kernel with them enabled is a trivial task for
any user familiar with ABS. If you feel this strongly about it please write
a wiki article about the benefits/tradeoffs and link it with the relevant
application articles (Firejail, Security, etc.).

Max
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

sivmu


Am 02.02.2017 um 05:10 schrieb Maxwell Anselm via arch-general:

>>
>> All those distros, everyone except arch has decided at some point to no
>> longer restrict the use of unprivileged user namespaces.
>>
>
> In no way whatsoever does Arch restrict the use of unprivileged user
> namespaces. Rebuilding your kernel with them enabled is a trivial task for
> any user familiar with ABS. If you feel this strongly about it please write
> a wiki article about the benefits/tradeoffs and link it with the relevant
> application articles (Firejail, Security, etc.).
>
> Max
>
This issue is about the default arch kernel disabling user namespaces
and the consequence that many applications have to use insecure
workarounds like suid to still work on arch.

This has nothing to do with the gernal ability to user user namespaces
on arch, this is about the default kernel.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

Doug Newgard-2
On Thu, 2 Feb 2017 05:13:46 +0100
sivmu <[hidden email]> wrote:

> Am 02.02.2017 um 05:10 schrieb Maxwell Anselm via arch-general:
> >>
> >> All those distros, everyone except arch has decided at some point to no
> >> longer restrict the use of unprivileged user namespaces.
> >>  
> >
> > In no way whatsoever does Arch restrict the use of unprivileged user
> > namespaces. Rebuilding your kernel with them enabled is a trivial task for
> > any user familiar with ABS. If you feel this strongly about it please write
> > a wiki article about the benefits/tradeoffs and link it with the relevant
> > application articles (Firejail, Security, etc.).
> >
> > Max
> >  
>
> This issue is about the default arch kernel disabling user namespaces
> and the consequence that many applications have to use insecure
> workarounds like suid to still work on arch.
>
> This has nothing to do with the gernal ability to user user namespaces
> on arch, this is about the default kernel.
>
You have said multiple times that Arch is restricting this. They're not. It's
simply not there by default, like just about everything in Arch. Build your own
kernel and move on.

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

Ralf Mardorf-4
In reply to this post by Leonid Isaev-3
On Wed, 1 Feb 2017 13:16:12 -0700, Leonid Isaev wrote:
>So, why don't you just build your own kernel? It takes only 20 mins...

I agree that users should build the kernel on their own, if they want
special features, but on many old machines it takes much longer to build
a kernel based on a default config. 180 minutes on my machine. It
might be that some hardware is broken, but in the past even the quickest
builds, when definitively all the hardware was ok, require around 90
minutes. FWIW I don't need this namespace thingy, but build rt patched
kernels myself.

I know what I'm taklking about, because last time I build a kernel on
my 2.1 dual-core, 4 GiB RAM yesterday ...

[root@moonstudio weremouse]# systemd-nspawn -qD /mnt/archlinux/ 2>/dev/null pacman -Qi linux-rt-rosaplüsch | grep Build
Build Date      : Wed Feb  1 14:24:47 2017

... and I build tons of kernels, not just for the connected hardware,
but with more or less default configs.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by sivmu
On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:

>
> 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)
Doing things properly is not easy.

> > > > 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.
The kernel configuration disables it by default. It enables UTS, IPC,
PID and NET namespaces by default. That's the opinion from upstream on
the sane default for a general purpose build: disabled.

It is quite clear that it's a major security risk. It exposes an endless
stream of privesc vulnerabilities from all of the attack surface it
adds. That attack surface was never exposed like that before and the
code is not at all robust against attackers, since it was only exposed
to root users before. It is going to take years for it to settle down
and become more like core kernel code that was already exposed, and it's
always going to be a ton of extra attack surface.

> > > > 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...
The documentation isn't wrong. Chromium never claims to have a mandatory
dependency on user namespaces since they've kept the setuid sandbox and
Android's documentation *definitely* doesn't claim to use them. Android
has never enabled user namespaces and has no use for them.


> > > >
> > >
> > > 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
There's no other kernel feature exposing all of that attack surface.

> > > 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.
sysctl:

user.max_cgroup_namespaces = 257166
user.max_ipc_namespaces = 257166
user.max_mnt_namespaces = 257166
user.max_net_namespaces = 257166
user.max_pid_namespaces = 257166
user.max_user_namespaces = 257166
user.max_uts_namespaces = 257166

A starting point is always setting max_user_namespaces to 0 by default,
and enabling the feature at compile-time. The proper way to do this is
not forcing people to toggle it on globally to use container software
depending on it though. It's scoped per userns and it's meant to be only
exposed where it's needed. The way the kernel implemented it makes this
painful, but it's doable. It would make sense to enable it, disabled by
default via the sysctl, with a policy to not automatically enable it in
packages, with the goal of a proper scoped implementation. Or just take
a sane approach to sandboxing / app containers...

> > > 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.
The majority of people working on desktop Linux security definitely have
no clue. It's a disaster and container tech is a terrible approach to
addressing it that brings many drawbacks vs. better solutions elsewhere.

I think it's laughable really. You can escape from all of these app
container 'sandbox' implementations via pulseaudio / dbus. The only
proper sandbox you named is the Chromium one, and it doesn't have a hard
dependency on this. It's only one of the options to make it work, and
they choose to do things differently elsewhere. It's all about the
expedience of using an available feature for a platform that's not
exactly first tier (desktop Linux) like ChromeOS, Android and Windows.

> 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.

It's not the last distribution to not have this enabled at all, and some
of the distributions enabling it are constraining it to be disabled by
default or only accessible to privileged users. The grsecurity patch set
restricts user namespaces to privileged users too.

> 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...

signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

arch general mailing list-2
In reply to this post by sivmu
So what's your alternatives/setup usable on Arch
(not android, not ChromeOS)? We heave disabled
SElinux, disabled Apparmor, disabled user
namespaces, PIE not enabled by default and only
partial relro. What's left then? Swimming naked?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: user namespaces

sivmu
In reply to this post by arch general mailing list-2


Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:

> On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
>>
>> 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)
>
> Doing things properly is not easy.
>
That's a bad attitude. It sounds like proper implementations need to be
difficult. That's not true. Especially security and above all crypto
fails often because it is hard to apply. That is why people like Bruce
Schneier have often talked about this. Dan Bernstein has created the
crypto library NaCl for that very reason, to allow the use of crypto
without overly complex and error prone implementations like needed by
openssl.

That is why this sentence is extremly wrong and dangerous.
If there is no way to privide users or developers with easy tools to
sandbox apps, then one has to be created. Just saying that doing things
properly isn't easy will do more harm then features like user namespaces
will ever be able to.

And if I am not mistaken, that is pretty much what android does: it
provides app developers with easy ways to drop privileges and sandbox
their apps.

Therefore I think the wish and need for easy ways to privode security is
important.

Bubblewrap is one of the concepts that I think do a great job on
providing easy isolation of apps, even if they utilise namespaces for
that purpose. (The Tor people seem to agree)

>>>>> 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.
>
> The kernel configuration disables it by default. It enables UTS, IPC,
> PID and NET namespaces by default. That's the opinion from upstream on
> the sane default for a general purpose build: disabled.
>
Tha is news to me actually. I was under the impression that all
namespaces were enabled by default. That changes things to some extend.

> It is quite clear that it's a major security risk. It exposes an endless
> stream of privesc vulnerabilities from all of the attack surface it
> adds. That attack surface was never exposed like that before and the
> code is not at all robust against attackers, since it was only exposed
> to root users before. It is going to take years for it to settle down
> and become more like core kernel code that was already exposed, and it's
> always going to be a ton of extra attack surface.
>

I recently talked about this with IT Sec people with kernel inside
knowledge and one strong opinion was that some enable this feature for
that exact reason. Because like many other features it will not evolve
if everyone disables it. Only the finding of vulnerabilities and design
flaws will lead to secure kernel features.



>>> 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.
>
> sysctl:
>
> user.max_cgroup_namespaces = 257166
> user.max_ipc_namespaces = 257166
> user.max_mnt_namespaces = 257166
> user.max_net_namespaces = 257166
> user.max_pid_namespaces = 257166
> user.max_user_namespaces = 257166
> user.max_uts_namespaces = 257166
>
> A starting point is always setting max_user_namespaces to 0 by default,
> and enabling the feature at compile-time. The proper way to do this is
> not forcing people to toggle it on globally to use container software
> depending on it though. It's scoped per userns and it's meant to be only
> exposed where it's needed. The way the kernel implemented it makes this
> painful, but it's doable. It would make sense to enable it, disabled by
> default via the sysctl, with a policy to not automatically enable it in
> packages, with the goal of a proper scoped implementation. Or just take
> a sane approach to sandboxing / app containers...
>
Thanks that is interesting.
Is there a comprehensive documentation about how to use this somewhere?




>>
>> 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.
>
> The majority of people working on desktop Linux security definitely have
> no clue. It's a disaster and container tech is a terrible approach to
> addressing it that brings many drawbacks vs. better solutions elsewhere.
>
Thats without a doubt correct, but Kernel maintainers from distros like
debian and red hat usually know what they are doing. Thats why I
question the reason the enabled this.


> I think it's laughable really. You can escape from all of these app
> container 'sandbox' implementations via pulseaudio / dbus.

Flatpak and firejail both block access to these services.
Even with bubblewrap/namespace-sandboxing alone you can easily block
them by not granting access to the domain socket files and using network
namespaces to block abstract sockets.
Does not seem like such a bad idea to me
(I not would recommend firejail though)

Not that there are not enoght weak points in sandboxing as long as
things like X11 are available.

But especially for things like, "parse this file and tell me if it is
malicious" a sandbox in an empty user/mount/pid/ipc/network namespace
with stong seccomp filters, can be quite useful. Even more so if you
need to do stuff like this anyway, sandboxed or not.


> The only
> proper sandbox you named is the Chromium one, and it doesn't have a hard
> dependency on this. It's only one of the options to make it work, and
> they choose to do things differently elsewhere. It's all about the
> expedience of using an available feature for a platform that's not
> exactly first tier (desktop Linux) like ChromeOS, Android and Windows.
>
>> 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.
>
> It's not the last distribution to not have this enabled at all, and some
> of the distributions enabling it are constraining it to be disabled by
> default or only accessible to privileged users. The grsecurity patch set
> restricts user namespaces to privileged users too.
>
Is there any chance to get the arch main kernel to use such a patch for
privileged user namespaces like with grsec?
That would at least reduce the aweful number of bugreports for many
projekts that use them this way.




signature.asc (836 bytes) Download Attachment
123
Loading...