[Android] Get renderers working again under seccomp-bpf.

[Android] Get renderers working again under seccomp-bpf.

Android 5.0 added some additional prctl()s that are used by the framework. This
also permits __NR_set_tid_address and fstat().

BUG=437067, 166704
R=jln@chromium.org

Committed: https://crrev.com/0d1b63a26471e4c3ac8acd12276010b79affc26a
Cr-Commit-Position: refs/heads/master@{#306895}

[Robert Sesek, 2014-12-03 21:13:57]

There are two patch sets here, let me know which approach you prefer. I think I
prefer allowing fstatat(), since we already allow open().

Brief overview of the issue:

The AssetManager tries to stat resource pack paths to determine what type of
file it is:
https://android.googlesource.com/platform/frameworks/base/+/lollipop-release/....
The function that returns the type of file doesn't handle EPERM though:
https://android.googlesource.com/platform/frameworks/base/+/lollipop-release/....
Since AssetManager can't stat any paths, it ends up not having any items in
mAssetPaths, and so AssetManager::getResTable() ends up returning NULL. This
appears to be unexpected, since several places test only if AssetManager is NULL
and not the result of ::getResources (e.g.
https://android.googlesource.com/platform/frameworks/base/+/lollipop-release/...).
The result is then a NULL deref.

[jln (very slow on Chromium), 2014-12-04 01:35:38]

lgtm

* Yeah, it seems ok to allow fstatat given the current model.

The drawback is that if we decided in the future to broker-out open() calls to
helper threads in the browser process, that will be one more thing to do. But
that's not the current intent anyways and it wouldn't be a difficult addition.

* What could we reasonably unit test here? Ideally make sure that some base::
stuff works sandboxed?

https://codereview.chromium.org/775943004/diff/20001/content/common/sandbox_l...
File content/common/sandbox_linux/android/sandbox_bpf_base_policy_android.cc
(right):

https://codereview.chromium.org/775943004/diff/20001/content/common/sandbox_l...
content/common/sandbox_linux/android/sandbox_bpf_base_policy_android.cc:43: #if
!ARCH_CPU_ARM64
Do you mind fixing this (to #if !defined()) as drive-by?

https://codereview.chromium.org/775943004/diff/20001/sandbox/linux/seccomp-bp...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/775943004/diff/20001/sandbox/linux/seccomp-bp...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:143:
.CASES((PR_SET_VMA, PR_SET_TIMERSLACK_PID), Allow())
Any reasonable way to add a unit test here?

Either call set_sched_policy() or figure out what the common caller is (any
thread creation?)

[Robert Sesek, 2014-12-04 17:56:59]

https://codereview.chromium.org/775943004/diff/20001/content/common/sandbox_l...
File content/common/sandbox_linux/android/sandbox_bpf_base_policy_android.cc
(right):

https://codereview.chromium.org/775943004/diff/20001/content/common/sandbox_l...
content/common/sandbox_linux/android/sandbox_bpf_base_policy_android.cc:43: #if
!ARCH_CPU_ARM64
On 2014/12/04 01:35:38, jln wrote:
> Do you mind fixing this (to #if !defined()) as drive-by?

Done.

https://codereview.chromium.org/775943004/diff/20001/sandbox/linux/seccomp-bp...
File sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
(right):

https://codereview.chromium.org/775943004/diff/20001/sandbox/linux/seccomp-bp...
sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc:143:
.CASES((PR_SET_VMA, PR_SET_TIMERSLACK_PID), Allow())
On 2014/12/04 01:35:38, jln wrote:
> Any reasonable way to add a unit test here?
> 
> Either call set_sched_policy() or figure out what the common caller is (any
> thread creation?)

No, I tried. There's no common caller, and most callers are in JNI functions.
set_sched_policy() isn't in the NDK either (it's defined in cutils, which is
private). Similar for all use of PR_SET_VMA.

I can test __NR_set_tid_address, but that's not too interesting, and it's in the
//content-level policy, rather than //sandbox :|

[Robert Sesek, 2014-12-04 20:32:34]

The CQ bit was checked by rsesek@chromium.org

[commit-bot: I haz the power, 2014-12-04 20:33:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/775943004/40001

[commit-bot: I haz the power, 2014-12-04 21:29:09]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2014-12-04 21:30:03]

Patchset 3 (id:??) landed as
https://crrev.com/0d1b63a26471e4c3ac8acd12276010b79affc26a
Cr-Commit-Position: refs/heads/master@{#306895}