[arch-general] user namespaces

[Daniel Micay]

On Thu, 2017-02-02 at 16:29 +0100, sivmu wrote:
> 
> 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.

Stop misrepresenting my position and arguing against strawmen. Providing
easy tools to sandbox applications is important. Those tools should be
robust and secure, which is the part that's not easy. That's clearly
what I was talking about, but you're only interested in trying to score
points without actually trying to understand but simply regurgitating
talking points without having a clue. User namespaces are not at all
necessary for providing unprivileged sandboxing. For example, SubgraphOS
doesn't use user namespaces.

You're the one doing harm, by wasting time and hurting the chances of
someone actually getting what you want done. User namespaces had a
higher chance of being enabled before you showed up, just like what
happened with moving away from using md5/sha1 for hashes in PKGBUILDs
and what happened with MAC.

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

Another argument to authority? Tor tries to build a privacy-oriented
browser on top of by far the least secure mainstream browser. Tails
doesn't (currently) even use a PaX / grsecurity kernel despite it being
fairly easy to integrate particularly for a distribution like that. It
doesn't use a full system MAC policy either. Is that really the ivory
tower you're looking to for advice?

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

All but user namespaces. The other namespaces do not present any real
risk by default, since only privileged users have access to them. User
namespaces greatly reduce security unless they are disabled at runtime.
A system designed around user namespaces can make sure that EVERYTHING
runs in a user namespace with user namespaces disabled within them, but
on a general purpose system it's a big problem, and that's also the case
for a general purpose system with a few sandboxes. Not to mention that
user namespaces accomplish essentially nothing for security and the only
reason you or anyone else wants them is fact that they open up the
unpriv use can of worms, but it's much less secure than alternative
approaches to that. It is NOT necessary or even desirable for that. It
is only wanted for the political reasons I've already gone into.

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

It will never be secure. It will ALWAYS unnecessarily introduce a whole
bunch of attack surface. Anyone making nonsense claims like that has
absolutely no clue about security and should not be trusted with
anything to do with it. Bug finding isn't ever going to change the fact
that this approach is insane.

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

You know what to look for now.

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

More arguments to authority and again pretending that you can speak for
developers of other projects.

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

The point is that they are truly not usable for sandboxing desktop apps
and that's the only niche that's not well covered already.


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

You don't need user namespaces to do sandboxing. You keep bringing up
irrelevant points and assuming that sandboxing or unprivileged
sandboxing depends on user namespaces. It does not. Other approaches to
unprivileged use can be inherently safer too.

Separately from that, generic sandboxing is a lot weaker than integrated
sandboxing which you imply by stating *strong* seccomp filters. In that
case namespaces are not really required.

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

I doubt it. Anyway, linux-grsec is in the official repositories. No one
really wants / needs user namespaces though. They want *unprivileged*
access to namespaces.

The uid/gid mapping stuff provided by user namespaces doesn't have much
use when you are already using a different approach to unprivileged
access. You can use dedicated uid/gids from reserved ranges instead. The
uid/gid mapping features may become less half-baked in the future as
support appears via filesystems, etc. for actually doing something
useful with them but right now there's little point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170202/5d0aa139/attachment.asc>