commit d267fd9917cb1c7494a8067ea3c6f1831bb37e78
author Matthew Denton <mpdenton@chromium.org> Wed Aug 08 19:21:00 2018
committer Commit Bot <commit-bot@chromium.org> Wed Aug 08 19:21:00 2018
tree 104ca5ecef4be253f56848535177f50e81b618e9
parent 24e5fbf1e9ca43c81405e257c1c13d74c0c233f7

Modified chrome://sandbox to more accurately describe sandboxing

Originally the chrome://sandbox page displayed "SUID Sandbox" as red
when the SUID sandbox was off, even if the namespace sandbox was on. To
avoid indicating that anything is wrong, this combines "SUID Sandbox"
and "Namespace Sandbox" into one row that displays green for namespace,
yellow for SUID, and red for neither.

Also, when the Chrome renderers are sandboxed with user namespaces,
any process in the parent namespace with the same UID is able to
ptrace the renderer. However, the chrome://sandbox page displays Yama
LSM as enforcing. This makes it clear that Yama LSM is not protecting
the renderer processes from ptrace by adding "Ptrace Protection with
Yama LSM (Non-broker)" to the webpage.

start chrome with all three sandboxing possibilities, run
./browser_tests --gtest_filter="Sandbox*"

Bug: 870527, 870534
Test: start chrome with Yama disabled, enabled, and with SetUID sandbox,
Change-Id: I2e4735363a4dceee4947757a74451e3e102c4250
Reviewed-on: https://chromium-review.googlesource.com/1162764
Commit-Queue: Matthew Denton <mpdenton@chromium.org>
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581656}