Snap rejected because of use of browser-support

I recently uploaded a snap to the store (couchdb-ryanjyoder), but it’s been rejected because it requires the interface browser-support. I have a few questions.

First can this be approved? If not is there a way to publish without a review (if the snap is private for example)?

I’ve read the documentation on “browser-support”, but it’s still not clear exactly which which resource it provides. Maybe those resources could be packaged with my snap?

What resource was your snap accessing which was denied until you added the browser-support plug to your yaml? This plug is designed to be specific for snaps containing chromium or firefox and not intended for widespread use. If we can get a bit more detail about your application and the denials it was experiencing we might be able to advise a better course than to request the browser-support usage and subsequent request for it’s auto-connection.

Well the short answer is i dont know what it’s accessing.

Some quick background. I wanted to install couchdb on my Raspberry Pi. The current snap (couchdb) is broken and not compiled for armhf. I forked the repo and tried to build my own snap. After some research I found out it needed the browser-support interface. It magicaly worked, but when I published it in the store it was rejected. I know it has something to do with the javascript map-reduce that couchdb does, because that’s when it fails. I read the documentation for browser-support to try to understand which resources it provides, to start tracking down the problem, but the docs were quite vague.

Not sure if this helps, but I get the following error when I build without browser-support.

Dec 2 22:37:54 localhost kernel: [ 1129.519379] audit: type=1326 audit(1512254274.125:84): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4477 comm="couchjs" exe="/snap/couchdb/x1/rel/couchdb/bin/couchjs" sig=31 arch=40000028 syscall=97 compat=0 ip=0x76c7ec06 code=0x0

I’m sorta spitballing here. But is it possible the binary couchjs is trying to access a shared library, one that is some how accessible when you have browser-support?

On amd64, syscall 97 is unshare, which is usually rejected by the seccomp profile snapd builds, but allowed by browser-support. The comment in the snapd source code says:

# Policy needed for Mozilla userns sandbox
unshare
quotactl

And CouchDB embed’s Mozilla’s JavaScript engine to execute sandboxed JavaScript to create views, so it doesn’t seem that surprising that it hits the same system calls.

Ah ok. Makes sense. What are my options then? Is there another interface I could use instead?

It looks like docker-support and network-control also allow the unshare system call, but I believe both of those will require manual review too. So browser-support may in fact be the best option absent an more specific interface.

If you haven’t already, you can log in to dashboard.snapcraft.io, find the revision for the snap you uploaded and request a manual review. That is probably the best way forward.

As for what browser-support actually does, you can get some idea from the AppArmor and seccomp fragments in the source code:

It basically punches a number of holes in Snapd’s default sandbox in order to allow Chromium and Firefox to run. Couchdb could probably run without most of that stuff, but it seems to need unshare at a minimum.

note that on armhf:

ogra@pi3:~$ scmp_sys_resolver 97
setpriority

not unshare … the process-control interface provides setpriority support …

FYI, you can use snappy-debug to help on your journey to strict confinement. Eg in a separate terminal/ssh session:

$ sudo snap install snappy-debug
$ sudo snappy-debug.security scanlog
...

Then in another, exercise your snap:

$ sudo snap install --dangerous /path/to/snap
$ sudo snap connect ... # connect any interfaces you plug

See Security policy and sandboxing for details.

For example:

Log: auid=1000 uid=0 gid=0 ses=581 pid=25966 comm="renice" exe="/usr/bin/renice" sig=31 arch=40000028 97(setpriority) compat=0 ip=0xb6e8ac06 code=0x0
Syscall: setpriority
Suggestion:
* add one of 'browser-support, process-control' to 'plugs'

So as @ogra said, plug ‘process-control’ instead of ‘browser-support’.

Note to others who used scmp_sys_resolver, syscalls have different numbers on different architectures and you need to carefully look at ‘arch’ in the denial. For example, in the above arch=40000028 corresponds to arm (arch=c000003e is for amd64, arch=c00000b7 for arm64, etc). You have to be careful using scmp_sys_resolver on other architectures. Eg, on my amd64 host:

$ scmp_sys_resolver 97 # use whatever arch the host is
getrlimit
$ scmp_sys_resolver -a x86_64 97 # specify amd64
getrlimit
$ scmp_sys_resolver -a aarch64 97 # specify arm64
unshare
$ scmp_sys_resolver -a arm 97 # specify armhf
setpriority

(this is also discussed in Security policy and sandboxing).

1 Like

Thank you! This was in fact the issue. I didn’t realize process-control needed to be manually connected. I had declared the process-control as a plug, but I didn’t connect it. Then, I added browser-support which auto-connects and that “fixed” the problem.

Long story short. I didn’t need browser-support, i just needed to connect the processs-control interface.

1 Like