Sandboxing with the browser-support interface

[retrocausal]

human review required due to ‘deny-connection’ constraint for ‘plug-attributes’ from base declaration. If using a chromium webview, you can disable the internal sandbox (eg, use --no-sandbox) and remove the ‘allow-sandbox’ attribute instead.

Questions:

1. What does browser-support do? and which snaps should use the interface?

2. Would atom, which essentially runs on headless chromium for all practical purposes, need sandboxing support as a browser would?

I see that for brave, the snapcraft file comments out this plug, and uses --no-sandbox as a command line argument/switch at run time

Questions:

1. Why is sandboxing not enabled for brave?

Lastly, that message itself on the store, for a snap that wishes to plug into sandboxing, doesn’t mean much.

As in isn’t it contradicting?

As a layman , from the docs on snapcraft,

• you can use sandboxing and browser support in general.

After you use it in snapcraft,

At the store upload,

• No! this cant be done. Use --no-sandbox for turning sandboxing off.

Me:

But I want to try and see what sandboxing does

[jdstrand]

The browser-support interface is described here: https://github.com/snapcore/snapd/wiki/Interfaces#browser-support

I’ll quote it here:

"

browser-support

Can access files and IPC needed by modern browsers. This interface is intended to be used when using an embedded Chromium Content API or using the sandboxes in major browsers from vendors like Google and Mozilla. The allow-sandbox attribute may be used to give the necessary access to use the browser’s sandbox functionality.

• Auto-Connect: no when allow-sandbox: true, yes otherwise
• Attributes:
  • allow-sandbox: true|false (defaults to false)

Note: for webapps that use electron or Oxide, it is often useful to disable the internal sandbox and rely on strict confinement so that the snap uses allow-sandbox: false. To do this:

• for electron, specify --no-sandbox on the command line for your app
• for Oxide webviews, export OXIDE_NO_SANDBOX=1

"

In other words, the snap will be confined no matter what and the --allow-sandbox attribute just controls whether or not the browser’s internal sandbox can be used. Since the browser’s internal sandbox requires a lot of privileged security policy rules to work, use of --allow-sandbox=true is limited to trusted publishers.

[retrocausal]

That cleared up a lot of anguish and anxiety to have a crack at everything snapcraft offers now

Thanks!

[jdstrand]

FYI, we discovered a problem in the base declaration for browser-support with the fix in https://github.com/snapcore/snapd/pull/4238 and this fix will be in snapd 2.30. Snaps that simply plugs: [ browser-support ] (ie, the vast majority of browser-support users) are not affected. For the few snaps that use allow-sandbox: true with the browser-support interface, when installing with --dangerous you will now have to manually connect the browser-support interface afterwards. The snap declarations in the store have been adjusted for these snaps so this will not affect end users.

I’ve adjusted https://github.com/snapcore/snapd/wiki/Interfaces#browser-support accordingly.