Linux sandbox: disallow fork() and *kill for ASAN

Linux sandbox: disallow fork() and *kill for ASAN

Treat ASAN like non-ASAN and disallow fork() and *kill there as well.

BUG=367986
R=jorgelo@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=267292

[jln (very slow on Chromium), 2014-04-30 01:22:04]

Jorge, Alexander, PTAL!

Alexander: I don't think there is any reason to treat ASAN in a special way, is
there?

Or is it creating threads without pthread? If the glibc flags are not
appropriate for ASAN, I can relax things a bit there
and simply forbid anything without CLONE_THREAD | CLONE_VM.

[earthdok, 2014-04-30 15:10:06]

On 2014/04/30 01:22:04, jln wrote:
> Jorge, Alexander, PTAL!
> 
> Alexander: I don't think there is any reason to treat ASAN in a special way,
is
> there?
> 
> Or is it creating threads without pthread? If the glibc flags are not
> appropriate for ASAN, I can relax things a bit there
> and simply forbid anything without CLONE_THREAD | CLONE_VM.

LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED".

[earthdok, 2014-04-30 15:21:16]

On 2014/04/30 15:10:06, earthdok wrote:
> On 2014/04/30 01:22:04, jln wrote:
> > Jorge, Alexander, PTAL!
> > 
> > Alexander: I don't think there is any reason to treat ASAN in a special way,
> is
> > there?
> > 
> > Or is it creating threads without pthread? If the glibc flags are not
> > appropriate for ASAN, I can relax things a bit there
> > and simply forbid anything without CLONE_THREAD | CLONE_VM.
> 
> LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED".

So does TSan, though I'm not sure in which situations (and whether they happen
in Chrome).

[jln (very slow on Chromium), 2014-04-30 15:50:17]

On 2014/04/30 15:21:16, earthdok wrote:
> On 2014/04/30 15:10:06, earthdok wrote:
> > On 2014/04/30 01:22:04, jln wrote:
> > > Jorge, Alexander, PTAL!
> > > 
> > > Alexander: I don't think there is any reason to treat ASAN in a special
way,
> > is
> > > there?
> > > 
> > > Or is it creating threads without pthread? If the glibc flags are not
> > > appropriate for ASAN, I can relax things a bit there
> > > and simply forbid anything without CLONE_THREAD | CLONE_VM.
> > 
> > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_UNTRACED".
> 
> So does TSan, though I'm not sure in which situations (and whether they happen
> in Chrome).

Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test LSAN
correctly. In which situation does it do that? Always, not only after a leak is
detected?

If you don't always use CLONE_THREAD, then I can't really block *kill in LSAN
because of the NSS bug.

[Jorge Lucangeli Obes, 2014-04-30 15:52:49]

lgtm % finding the right set of flags.

[earthdok, 2014-04-30 16:01:14]

On 2014/04/30 15:50:17, jln wrote:
> On 2014/04/30 15:21:16, earthdok wrote:
> > On 2014/04/30 15:10:06, earthdok wrote:
> > > On 2014/04/30 01:22:04, jln wrote:
> > > > Jorge, Alexander, PTAL!
> > > > 
> > > > Alexander: I don't think there is any reason to treat ASAN in a special
> way,
> > > is
> > > > there?
> > > > 
> > > > Or is it creating threads without pthread? If the glibc flags are not
> > > > appropriate for ASAN, I can relax things a bit there
> > > > and simply forbid anything without CLONE_THREAD | CLONE_VM.
> > > 
> > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES |
> CLONE_UNTRACED".
> > 
> > So does TSan, though I'm not sure in which situations (and whether they
happen
> > in Chrome).
> 
> Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test
LSAN
> correctly. In which situation does it do that? Always, not only after a leak
is
> detected?
Always. The leak detection routine is run on this special thread. The reason is
that it must have direct access to parent's address space (for performance) but
not be part of the same thread group (because otherwise ptrace would not work).

> If you don't always use CLONE_THREAD, then I can't really block *kill in LSAN
> because of the NSS bug.

[jln (very slow on Chromium), 2014-04-30 16:09:26]

On 2014/04/30 16:01:14, earthdok wrote:
> On 2014/04/30 15:50:17, jln wrote:
> > On 2014/04/30 15:21:16, earthdok wrote:
> > > On 2014/04/30 15:10:06, earthdok wrote:
> > > > On 2014/04/30 01:22:04, jln wrote:
> > > > > Jorge, Alexander, PTAL!
> > > > > 
> > > > > Alexander: I don't think there is any reason to treat ASAN in a
special
> > way,
> > > > is
> > > > > there?
> > > > > 
> > > > > Or is it creating threads without pthread? If the glibc flags are not
> > > > > appropriate for ASAN, I can relax things a bit there
> > > > > and simply forbid anything without CLONE_THREAD | CLONE_VM.
> > > > 
> > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES |
> > CLONE_UNTRACED".
> > > 
> > > So does TSan, though I'm not sure in which situations (and whether they
> happen
> > > in Chrome).
> > 
> > Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test
> LSAN
> > correctly. In which situation does it do that? Always, not only after a leak
> is
> > detected?
> Always. The leak detection routine is run on this special thread. The reason
is
> that it must have direct access to parent's address space (for performance)
but
> not be part of the same thread group (because otherwise ptrace would not
work).

Ok, thanks for the explanation. I could actually still EPERM the NSS case by
EPERMing any clone without CLONE_VM. But do you need *kill to work on something
else than the main process? For instance, does the LSAN "thread", signal the
main thread group?

[earthdok, 2014-04-30 16:25:15]

On 2014/04/30 16:09:26, jln wrote:
> On 2014/04/30 16:01:14, earthdok wrote:
> > On 2014/04/30 15:50:17, jln wrote:
> > > On 2014/04/30 15:21:16, earthdok wrote:
> > > > On 2014/04/30 15:10:06, earthdok wrote:
> > > > > On 2014/04/30 01:22:04, jln wrote:
> > > > > > Jorge, Alexander, PTAL!
> > > > > > 
> > > > > > Alexander: I don't think there is any reason to treat ASAN in a
> special
> > > way,
> > > > > is
> > > > > > there?
> > > > > > 
> > > > > > Or is it creating threads without pthread? If the glibc flags are
not
> > > > > > appropriate for ASAN, I can relax things a bit there
> > > > > > and simply forbid anything without CLONE_THREAD | CLONE_VM.
> > > > > 
> > > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES |
> > > CLONE_UNTRACED".
> > > > 
> > > > So does TSan, though I'm not sure in which situations (and whether they
> > happen
> > > > in Chrome).
> > > 
> > > Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't
test
> > LSAN
> > > correctly. In which situation does it do that? Always, not only after a
leak
> > is
> > > detected?
> > Always. The leak detection routine is run on this special thread. The reason
> is
> > that it must have direct access to parent's address space (for performance)
> but
> > not be part of the same thread group (because otherwise ptrace would not
> work).
> 
> Ok, thanks for the explanation. I could actually still EPERM the NSS case by
> EPERMing any clone without CLONE_VM. But do you need *kill to work on
something
> else than the main process? For instance, does the LSAN "thread", signal the
> main thread group?

The LSan "thread" does not send any signals. It may send ptrace requests though.

[jln (very slow on Chromium), 2014-04-30 16:29:15]

On 2014/04/30 16:25:15, earthdok wrote:

> The LSan "thread" does not send any signals. It may send ptrace requests
though.

And the main thread group doesn't signal it either? How does it die?

Moreover, doesn't this "thread" get started before the sandbox? This would
completely break the sandboxing model.

Does LSAN run with the sandbox at all? I thought not. In which case all is good
and I'd proceed with the current patch. We should simply keep in mind that LSAN
would silently disable the sandbox if it start its "thread" before the sandbox
is engaged.

[earthdok, 2014-04-30 16:43:07]

On 2014/04/30 16:29:15, jln wrote:
> On 2014/04/30 16:25:15, earthdok wrote:
> 
> > The LSan "thread" does not send any signals. It may send ptrace requests
> though.
> 
> And the main thread group doesn't signal it either?
No.

> How does it die?
It runs until it's done, and then exits.

> Moreover, doesn't this "thread" get started before the sandbox? This would
> completely break the sandboxing model.
It starts when leak detection is triggered, which is just before process
termination. Moreover, the main thread group is suspended until the special
thread finishes its work.

> Does LSAN run with the sandbox at all? I thought not.
Not currently, but hopefully will at some point in the future.

> In which case all is good
> and I'd proceed with the current patch. We should simply keep in mind that
LSAN
> would silently disable the sandbox if it start its "thread" before the sandbox
> is engaged.

[jln (very slow on Chromium), 2014-04-30 16:53:05]

On 2014/04/30 16:43:07, earthdok wrote:
> On 2014/04/30 16:29:15, jln wrote:
> > On 2014/04/30 16:25:15, earthdok wrote:
> > 
> > > The LSan "thread" does not send any signals. It may send ptrace requests
> > though.
> > 
> > And the main thread group doesn't signal it either?
> No.
> 
> > How does it die?
> It runs until it's done, and then exits.
> 
> > Moreover, doesn't this "thread" get started before the sandbox? This would
> > completely break the sandboxing model.
> It starts when leak detection is triggered, which is just before process
> termination. Moreover, the main thread group is suspended until the special
> thread finishes its work.
> 
> > Does LSAN run with the sandbox at all? I thought not.
> Not currently, but hopefully will at some point in the future.

Ok, thanks! I'll land the change as-is then. When we want to try and make LSAN
work with the sandbox, I'm happy to poke certain holes, as long as we have a way
to detect LSAN
(detecting dynamically - via environment for instance - is fine).

[jln (very slow on Chromium), 2014-04-30 19:21:13]

Committed patchset #3 manually as r267292 (presubmit successful).