[ubuntu-hardened] Firefox's sandbox, restricting user_namespaces(7) - a new User Namespaces for privileged processes entry.

[Seth Arnold]

On Wed, Jun 07, 2017 at 06:52:57PM +0200, daniel curtis wrote:
> Because of all security issues found in the past, related to the user
> namespaces and since it has opened up a large attack surface to
> unprivileged users, e.g. CVE-2016-8655 (introduced in Linux v3.2-rc1 and
> fixed in v4.9-rc8) exploitable by arbitrary user if mentioned sysctl key
> value was '1' (which is a default setting, by the way), I have some
> questions.
> 
> (Generally, a mitigation for a mentioned issues is simple; restricting user
> namespaces usage only to privileged users by using '0'.)

Hello Daniel,

Yes, we ship our kernels with user namespaces enabled. This is one of the
reasons why Docker, LXC, LXD and similar tools are popular on Ubuntu.

We allow disabling the feature via sysctl for sysadmins who do not use
these features, do not care about the browser sandboxing tools, and want
to reduce their exposure to this class of vulnerabilities. (Think
"traditional servers" here.)

> I changed "kernel.unprivileged_userns_clone" key value from a default '1'
> to '0', on my testing machine, running 16.04 LTS Release. Because this step
> could have an impact on a containers etc., I decided to check Firefox's
> sandbox settings via 'about:support' page. And there was some changes! By
> default all four options are set to "true". Let's see;
> 
> ✗ Seccomp-BPF (System Call Filtering) true
> ✗ Seccomp Thread Synchronization true
> ✗ User Namespaces true
> ✗ Plugin Sandboxing true
> 
> But after changing the 'kernel.unprivileged_userns_clone' key value to '0'
> and after loading settings with sysctl(8) command and '-p' parameter, an
> additional entry appeared and one value had changed to "false". Now it
> looks that way:
> 
> ✗ Seccomp-BPF (System Call Filtering) true
> ✗ Seccomp Thread Synchronization true
> ✓ User Namespaces for privileged processes true
> ✗ User Namespaces false
> ✗ Plugin Sandboxing true
> 
> As we can see, after mentioned change, Firefox's 53.0.3 sandbox has a new
> one key for privileged processes. What do you think about this? And what
> about Firefox; can this change affect the sandbox in some way? Or maybe
> this change is really more secure?

This was fun to track down. :) Thanks for the question.

Between Linux 2.6.23 and 3.8 new user namespaces could be created only
by privileged processes. In Linux 3.8 the restrictions were relaxed to
allow unprivileged processes to also create new user namespaces.

Firefox tests these properties at startup -- and they have chosen to
simplify the display if unprivileged user namespaces are supported by not
reporting privileged user namespaces. If unprivileged user namespaces are
not supported, they report that, and report if privileged user namespaces
are supported.

This drastically affects the sandbox -- to my knowledge Firefox has no
support for privileged user namespaces. (This would require shipping at
least one executable file setuid root or using filesystem capabilities to
be essentially setuid root. This would be a very enticing target.)

So if you turn off unprivileged user namespaces you no longer use that
portion of the Firefox sandbox.

I can't tell you if this is more or less secure. It removes portions of
the kernel attack surface from Firefox but also prevents it from using
unprivileged user namespaces to isolate itself from your other processes.

AppArmor's interactions with unprivileged user namespaces is currently
unfortunate -- you must grant e.g. capability sys_admin to any process
which intends to use them, which means if real root ever runs Firefox
(bad idea) then Firefox actually has all the privileges that CAP_SYS_ADMIN
conveys with it.

Note that using AppArmor profiles doesn't make your system less secure
in this case. We're just sad that the current state of affairs doesn't
remove as much authority as it could.

> I would like to ask also, what effects can I expecting after this change?
> I'm thinking about situation when e.g. there is no containers in use (I
> mean LXC, for example), system behavior and so on.

With this change, LXC and LXD are limited to only privileged user
namespaces. I don't know Docker well enough to say how it copes:
probably poorly. Chromium-browser and Firefox don't get to use their
internal sandboxing.

Even if you decide today that you'd be better off disabling unprivileged
user namespaces, keep an open mind about it for the future:

- As more people gain more experience with unprivileged user namespaces,
  the kernel's 'new' attack surfaces will be better audited and better
  protected.

- As more people see the benefits of privilege separation we may see
  further deployments of sandboxing tools. (Consider this a personal plea
  for people who depend upon image handling tools to invest in sandboxing,
  mandatory access control, etc.)

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20170607/23009d5a/attachment.pgp>