> If the renderer process sandbox was changed to allow read/write access to a file

If a renderer process sandbox had read/write access to arbitrary files, this would itself be a significant vulnerability.

I'll let one of our sandbox experts comment on the proposed hardening.

>> If the renderer process sandbox was changed to allow
>> read/write access to a file

> If a renderer process sandbox had read/write access to arbitrary
> files, this would itself be a significant vulnerability.

Hi, by "changed to allow read/write access to a file", I meant read/write access to a single file, not arbitrary access to files. For example, the renderer has write access to a log file now. If the sandbox was changed to also allow read access to the log file, that would be sufficient to use CTFontManagerRegisterFontsForURL() to bypass the sandbox read access restrictions. I don't think it's a problem now, but I think it makes sense to protect against. One wouldn't expect that allowing read/write access to a single file in the renderer sandbox rules would have this side effect.

Thanks for the report, this is an interesting find!

I agree with your assessment that this isn't exploitable. Generally we don't want to give any file-write access to processes (except through brokered FDs), so I think the risk is low. However, defense-in-depth is a good policy, and this is subtle enough that having extra checks would be beneficial.

I think suggested change (1) is a good idea. We may even want to take it a step further and make it a macro to be used instead of file-write* to ensure that we always only write to regular files.

The concern you raise about (2) is probably going to occur for our users, so I'm less convinced we should make that change.

I've also been thinking that we may want to get rid of the current FontLoader implementation and switch to granting seatbelt extensions for font files (a much larger change than this bug).

Passing this over to Greg who's working on the sandbox policies now for looking at 1 and 2.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/411ce7e1c0d06419ebb9174d34560ab7653f4057

commit 411ce7e1c0d06419ebb9174d34560ab7653f4057
Author: Greg Kerr <kerrnel@chromium.org>
Date: Fri Dec 15 18:25:43 2017

macOS V2 Sandbox: Harden sandbox by specifying vnode-type for writes.

This hardens the macOS sandbox by specifying an explicit vnode type for
all writeable files, reducing the risk that an attacker can symlink a
file Chrome has write access to, and modify the filesystem at will.

Bug:  793402 
Change-Id: I53bbcc84345e432756eff0d2dc18a505719fd521
Reviewed-on: https://chromium-review.googlesource.com/829877
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Greg Kerr <kerrnel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524413}
[modify] https://crrev.com/411ce7e1c0d06419ebb9174d34560ab7653f4057/services/service_manager/sandbox/mac/common_v2.sb
[modify] https://crrev.com/411ce7e1c0d06419ebb9174d34560ab7653f4057/services/service_manager/sandbox/mac/renderer_v2.sb

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

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Thanks for the report, haik.aftandilian@! The VRP panel has been looking at older bugs with security_impact-None and decided to award $500. A member of our finance team will be in touch to arrange payment. Cheers!