[arch-general] sandboxing

[Leonid Isaev]

On Thu, Feb 02, 2017 at 03:24:11AM +0100, sivmu wrote:
> 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.

Why? Your browser is in effect an execution env for untrusted code. So, of
course it requires isolation. The same applies to any PDF reader that is
capable of doing javascript etc. But the question is do we need such features?

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

It's not about secure coding, but about feature creep. If you want you insist
on executing arbitrary code, then the only sane strategy is to use that program
in a VM.

> Please take a look at bubblewrap
> https://github.com/projectatomic/bubblewrap
> On the default arch kernel it does not use user namespaces.

And? Why do you point out such projects?

I already described an approach when one always runs browsers, pdf readers,
etc, inside an lxc container, as an unprivileged user. That container resides
on a filesystem mounted with nosuid (so things like ping, su, sudo won't work),
and has a locked root account. On top of that, it connects to a xephyr session
running on the host, to avoid X11 sniffing attacks.

I have been using such setup on all my desktops for over a year now. The only
way to break out of such a container is a local kernel privilege escalation. Of
course, having *privileged* userns *might* help because inside container UID=0
will map to smth like UID=123456 on the host, but this doesn't seem worth doing
given all the ussues with userns.

I should also point out that linux upstream refuses to accept a patch providing
a sysctl switch between unprivileged and privilieged userns.

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

Any distribution that says "we focus on security" is garbage because security
depends on the user's threat model. A distro should provide the *basic* tools
that enable the user to implement his security demands.

But tails is worse than garbage -- it is malicious, because it also focuses on
privacy, forgetting that user's privacy is almost synonomous to his education.
So, there is no such thing as "easy privacy" or "easy security".

And no, pls don't bring up the breakage that you call OpenBSD...

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

Why? My sandbox is better than that of chromium.

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

Docker is not a security mechanism because its mission is totally different.
Secure sandbox is always maximally isolated, while docker puts emphasis on as
much sharing as possible, for efficiency.

Also, SECURITY != TOOL. So, unless you understand what grsecurity does, don't
use it.

Cheers,
-- 
Leonid Isaev