Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1315282 > unrolled thread

Re: fs: sandboxed process brings host down

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: fs: sandboxed process brings host down Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-22 22:30 +0100
    Re: fs: sandboxed process brings host down Dmitry Vyukov <dvyukov@google.com> - 2016-01-22 22:40 +0100
      Re: fs: sandboxed process brings host down Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-22 23:00 +0100
        Re: fs: sandboxed process brings host down Robert Święcki <robert@swiecki.net> - 2016-01-22 23:40 +0100
    Re: fs: sandboxed process brings host down Kees Cook <keescook@google.com> - 2016-01-22 22:50 +0100

#1315282 — Re: fs: sandboxed process brings host down

On Fri, Jan 22, 2016 at 10:06:14PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> While running syzkaller fuzzer I hit the following problem. Supervisor
> process sandboxes worker processes that do random activities with
> CLONE_NEWUSER | CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUTS |
> CLONE_NEWNET | CLONE_NEWIPC | CLONE_IO, setrlimit, chroot, etc.
> Because of that worker process gains ability to bring whole machine
> down (does not happen without the sandbox).

AFAICS, what you are doing is essentially mount --rbind / / in infinite
loop in luserns.  Which ends up eating all memory.  There's any number
of ways to do the same.  We can play whack-a-mole with them until the
kernel is completely ossified with accounting code of different sorts.
Or one can disable userns and be done with that.

[toc] | [next] | [standalone]

#1315301

On Fri, Jan 22, 2016 at 10:21 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jan 22, 2016 at 10:06:14PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> While running syzkaller fuzzer I hit the following problem. Supervisor
>> process sandboxes worker processes that do random activities with
>> CLONE_NEWUSER | CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUTS |
>> CLONE_NEWNET | CLONE_NEWIPC | CLONE_IO, setrlimit, chroot, etc.
>> Because of that worker process gains ability to bring whole machine
>> down (does not happen without the sandbox).
>
> AFAICS, what you are doing is essentially mount --rbind / / in infinite
> loop in luserns.  Which ends up eating all memory.  There's any number
> of ways to do the same.  We can play whack-a-mole with them until the
> kernel is completely ossified with accounting code of different sorts.
> Or one can disable userns and be done with that.

My 2GB VM dies at around just 10-th iteration, is it normal?
Each iteration consumes several hundreds of megs of kernel memory. And
there seems to be exponential slowdown at around 5-th iteration.
I understand that there can be lots of forms of a local DoS. But there
seems to be something pathological about this particular one. And it
happens only with sandboxing that is meant to reduce DoS
possibilities...

[toc] | [prev] | [next] | [standalone]

#1315312

On Fri, Jan 22, 2016 at 10:38:40PM +0100, Dmitry Vyukov wrote:

> My 2GB VM dies at around just 10-th iteration, is it normal?
> Each iteration consumes several hundreds of megs of kernel memory. And
> there seems to be exponential slowdown at around 5-th iteration.
> I understand that there can be lots of forms of a local DoS. But there
> seems to be something pathological about this particular one. And it
> happens only with sandboxing that is meant to reduce DoS
> possibilities...

Sandboxing == giving attacker to do mount without being root.

As for exponential - sure, you double the amount of mounts on each step
(if not quadruple - I don't have your code in front of me right now,
but ISTR two mount --rbind in there).  More obvious form would be
for i in `seq 64`; do mkdir /tmp/$i; mount --rbind / /tmp/$i; done - there
the entire tree would be visible (and visibly exponential by the number of
iterations).

I doubt that the first iteration chews hundreds of megs, BTW.  If you
really get two mount --rbind per iteration, you would have about a million-fold
increase of the number of mounts after ten iterations, and having that chew
2Gb is quite plausible; in that case the first iteration would eat about 10K
or so...

[toc] | [prev] | [next] | [standalone]

#1315330

2016-01-22 22:55 GMT+01:00 Al Viro <viro@zeniv.linux.org.uk>:
> On Fri, Jan 22, 2016 at 10:38:40PM +0100, Dmitry Vyukov wrote:
>
>> My 2GB VM dies at around just 10-th iteration, is it normal?
>> Each iteration consumes several hundreds of megs of kernel memory. And
>> there seems to be exponential slowdown at around 5-th iteration.
>> I understand that there can be lots of forms of a local DoS. But there
>> seems to be something pathological about this particular one. And it
>> happens only with sandboxing that is meant to reduce DoS
>> possibilities...
>
> Sandboxing == giving attacker to do mount without being root.

I was discussing this initially with Dmitry and maybe I explained it
initially a bit incorrectly. I did not mean to suggest that using
CLONE_NEWUSER alone is a form of sandboxing. But rather, that when
used correctly (with dropping capabilities, rlimits and seccomp-bpf
filters) it could constitute a form of sandboxing.

What I suggested was to use CLONE_NEWUSER and friends to test the new
attack surface, which is enabled by using CLONE_NEW*. For regular
users the syscall(__NR_mount) returns early with EPERM, but when
CLONE_NEW* are used, a new, big attack surface opens up, reachable
from a level of a unprivileged user.

So, I guess, it's not about sandboxing but the newly reachable attack surface.

-- 
Robert Święcki

[toc] | [prev] | [next] | [standalone]

#1315310

On Fri, Jan 22, 2016 at 1:21 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jan 22, 2016 at 10:06:14PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> While running syzkaller fuzzer I hit the following problem. Supervisor
>> process sandboxes worker processes that do random activities with
>> CLONE_NEWUSER | CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUTS |
>> CLONE_NEWNET | CLONE_NEWIPC | CLONE_IO, setrlimit, chroot, etc.
>> Because of that worker process gains ability to bring whole machine
>> down (does not happen without the sandbox).
>
> AFAICS, what you are doing is essentially mount --rbind / / in infinite
> loop in luserns.  Which ends up eating all memory.  There's any number
> of ways to do the same.  We can play whack-a-mole with them until the
> kernel is completely ossified with accounting code of different sorts.
> Or one can disable userns and be done with that.

I think it's time for a runtime tunable to disable userns. For all the
distro users that are forced to run with kernels built with
CONFIG_USER_NS, there's no way for them to escape these USER_NS flaws
when they don't use the feature.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web