Request browser-support with allow-sandbox and a suid chrome-sandbox for growser

store-requests
1

Hello,

I would like to request two grants for the growser snap. Revision 2 (amd64, version 26.909.3) is uploaded and held: its automated review flags the two things every strict browser snap needs granted by hand:

  • browser-support with allow-sandbox: true
  • an entry in sec_mode_overrides for the setuid binary ./opt/growser/chrome-sandbox (mode r-sr-xr-x)

What the snap is. Growser is a Chromium-based web browser, built from a fork of brave-core. It is published from https://growser.org and the sources are at GitHub - dsfox-idea/brave-core: Core engine for the Brave browser for mobile and desktop. For issues https://github.com/brave/brave-browser/issues · GitHub . The snap is strict, base: core22, and is assembled from the same .deb we publish in our own apt repository.

Why the sandbox attribute is needed. The browser runs its renderers in Chromium’s own multi-process sandbox. Without allow-sandbox: true the only alternative the review message offers is --no-sandbox, which disables that process isolation entirely - for a web browser that is a security regression, not a packaging detail. The setuid chrome-sandbox helper is the same mechanism, and it is shipped unmodified from the upstream Chromium build.

Precedent. This is the same pair of declarations every Chromium-based browser in the store already carries. Canonical’s own chromium snap declares

plugs:
  browser-sandbox:
    interface: browser-support
    allow-sandbox: true

and ships usr/lib/chromium-browser/chrome-sandbox with mode r-sr-xr-x, which is in sec_mode_overrides in the review tools alongside brave, skype and zoom-client.

What else the review says. Nothing. I ran review-tools locally against the package: these two are the only errors, there are no warnings, and adding both grants brings the review to zero.

Happy to answer any questions or to provide the snap for inspection.

Thank you.

2

This request has been added to the queue for review by the @reviewers team.

3

It actually is a packaging detail in the light that the snap sandbox is a lot more restricted than the browser sandbox which is why we generally advise electron and chromium packaged snap apps to turn off the browser sandbox and to resort to the (actually root safe) snap confinement instead.

Does dropping the sandbox from the browser in any way impact the functionality of your snap ?

4

Hi and thx for reply! I measured it. Same build, one machine, inside snap confinement:

  1. setuid chrome-sandbox → not connected → runs, renderers sandboxed
  2. helper, not setuid → with allow-sandbox → Chromium aborts by design
  3. no helper → plain, connected → “No usable sandbox!”, will not start
  4. no helper → with allow-sandbox, connected → runs, renderers sandboxed

So I withdraw the second request: the setuid binary is gone. With allow-sandbox granted, Chromium uses its namespace sandbox and the package carries no setuid file at all — one item in review-tools instead of two, and one less thing than chromium itself ships (I checked: 152.0.7977.82 still carries usr/lib/chromium-browser/chrome-sandbox at r-sr-xr-x, and declares browser-support with allow-sandbox: true).

allow-sandbox I would still ask for. Snap confinement protects the system from the browser, and does it well. Inside the snap it is one profile for the whole app, so with --no-sandbox a compromised renderer inherits everything the snap may do: home, removable-media, the network, and the browser’s own profile with its cookies and passwords. That boundary is the product here — the browser has no accounts, no telemetry and no advertising, and its whole claim is that page data stays on the machine.

To answer exactly what you asked: dropping the browser sandbox breaks no functionality. It removes an isolation boundary inside the snap.

One practical point about the grant. Now that the helper is gone, the browser cannot start at all unless the interface is connected — the third row above. If the grant covers connection but not auto-connection, everyone who installs growser from the store gets a browser that refuses to launch until they run snap connect by hand. So please include auto-connection, or tell me if you would rather I keep a fallback in the snap for the unconnected case.

Happy to upload the rebuilt revision for inspection.

5

Hello @dsfox,

Auto-connection in these cases is considered highly-privileged and is reserved for mature, well-known applications and publishers. As @ogra mentions above and is briefly touched on in this forum post, usage of the browser sandbox results in the snap receiving a larger set of privileges than the base strict confinement provides, including potential vectors for confinement escape. For snaps, this is prioritized over within-snap isolation. From my understanding, you have confirmed that proceeding with allow-sandbox: false does not break snap functionality, and as such that is my recommended path forward.

Considering these factors, this is a -1 from me for granting usage of or auto-connection for the browser-support interface with allow-sandbox: true. What do other @reviewers think?

7

Thank you both, understood. I will take the recommended path: the next revision declares browser-support without allow-sandbox, passes --no-sandbox, and ships no setuid file. With that, nothing in this request is left to grant - plain browser-support auto-connects under the base declaration - so the request can be closed and revision 2 dropped; the rebuilt snap will come as a new revision.

If it becomes reasonable to grant the browser sandbox later, I will open a new request then.

2 Likes