-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux SUID sandbox doesn't work in Brave #6247
Comments
CCing @fmarier. |
You're right, that was added in #5502 in order to make Brave work in the default Debian configuration (while user namespaces are enabled by default in Ubuntu, they're not in Debian). The reason why we require user namespaces is that the chrome sandbox is deprecated: #1986 (comment) Thanks for pointing out that renaming/symlinking the sandbox binary makes it work. Based on what we've heard from Chromium developers however, this is not likely to work in the long run as user namespaces is the only mechanism that's supported upstream. |
…#7506) Now that the SUID sandbox is fixed (brave/brave-browser#6247), it is no longer required to enable user namespaces in order to use Brave.
Verification passed on
Verified test plan from brave/brave-core#4223 |
Only allow ptrace from a parent process to its children or via CAP_SYS_PTRACE. To verify sandbox status for Brave, Chrome, Firefox see brave://sandbox, chrome://sandbox, about:support, respectively. Also describe disadvantages of enabling unprivileged user namespaces. Distributions like Debian currently disable unprivileged user namespaces by default to decrease the kernel attack surface for local privilege escalation. See Debian bug #898446. If kept disabled, Brave 1.2+ and Chrome will still enforce namespace sandboxing via their setuid-root helper executable. See brave/brave-browser#3420 and brave/brave-browser#6247. Firefox does not include a setuid-root binary, however, so unprivileged user namespaces are useful to have for defence-in-depth, but not critical. See <https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html>.
Only allow ptrace from a parent process to its children or via CAP_SYS_PTRACE. To verify sandbox status for Brave, Chrome, Firefox see brave://sandbox, chrome://sandbox, about:support, respectively. Also describe disadvantages of enabling unprivileged user namespaces. Distributions like Debian currently disable unprivileged user namespaces by default to decrease the kernel attack surface for local privilege escalation. See Debian bug #898446. If kept disabled, Brave 1.2+ and Chrome will still enforce namespace sandboxing via their setuid-root helper executable. See brave/brave-browser#3420 and brave/brave-browser#6247. Firefox does not include a setuid-root binary, however, so unprivileged user namespaces are useful to have for defence-in-depth, but not critical. See <https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html>.
I noticed that when the
brave-keyring
debian package is installed, it manipulates thekernel.unprivileged_userns_clone
setting, and the option is set to1
. Why do you do this? All the other browsers (chromium, google-chrome, opera) work fine withkernel.unprivileged_userns_clone
set to0
. In such case, the browses simply execute the *-sandbox
binary. But in the case of brave, when the optionkernel.unprivileged_userns_clone
is set to0
I get the following error:I also noticed that the
/opt/brave.com/brave/brave-sandbox
binary isn't executed at all. Thestrace
said that /opt/brave.com/brave/chrome
-sandboxnot found
. I created a link tobrave-sandbox
and called itchrome-sandbox
Now when I start
brave-browser
it works and executes its sandbox like the other browsers executes theirs:So what do you think about creating this little
chrome-sandbox
link? In this way the brave browser would support both of the values (0/1) in thekernel.unprivileged_userns_clone
option, and you wouldn't have to manipulate with sysctl kernel parameters, which isn't really a good thing.The text was updated successfully, but these errors were encountered: