Chrome "sandbox" page says Yama enforcing when namespace sandbox is enabled |
||||
Issue descriptionOn Linux, chrome://sandbox displays "Yama LSM Enforcing" as "yes" even when "Namespace Sandbox" is "yes". But, when the namespace sandbox is enabled, Yama provides no ptrace protection for any processes in the new user namespace. (see https://bugs.chromium.org/p/chromium/issues/detail?id=862170) So, we need to split the "Yama LSM Enforcing" label into two labels: "Yama LSM Enforcing (broker)" and "Yama LSM Enforcing (non-broker)". The former will be always green when Yama is enabled on the system. The latter will be yellow (instead of red) when the user namespace sandbox is enabled, and green when the namespace sandbox is disabled and Yama is enabled.
,
Aug 3
I put that in a separate bug 870534 .
,
Aug 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d267fd9917cb1c7494a8067ea3c6f1831bb37e78 commit d267fd9917cb1c7494a8067ea3c6f1831bb37e78 Author: Matthew Denton <mpdenton@chromium.org> Date: Wed Aug 08 19:21:00 2018 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} [modify] https://crrev.com/d267fd9917cb1c7494a8067ea3c6f1831bb37e78/chrome/browser/resources/sandbox_internals/sandbox_internals.html [modify] https://crrev.com/d267fd9917cb1c7494a8067ea3c6f1831bb37e78/chrome/browser/resources/sandbox_internals/sandbox_internals.js [modify] https://crrev.com/d267fd9917cb1c7494a8067ea3c6f1831bb37e78/chrome/browser/ui/webui/sandbox_internals_ui.cc [modify] https://crrev.com/d267fd9917cb1c7494a8067ea3c6f1831bb37e78/chrome/test/data/webui/sandboxstatus_browsertest.js
,
Aug 20
,
Aug 21
,
Nov 27
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by palmer@chromium.org
, Aug 3