We have a snap that exposes a gRPC server over a Unix socket so other snaps can call it. We provide this API through a content interface like the content interface doc talks about. However, just using this interface is not enough - it fails to bind. We don’t want to use network-bind interface for this because this implies that the snap could expose something on an ethernet interface - which we don’t want to do from a mandatory access control policy point of view.
Is there a better interface that just allows bind? If not, should one be added? Or perhaps a specific unix socket interface that is like a content interface but adds binding?
Actually, this particular service is not a gRPC server but a REST server over a unix socket. Weirdly, it doesn’t look like we needed the network-bind interface for gRPC 
.
1 Like
I did some more digging and it wasn’t related to REST vs gRPC. Looking more closely at the snapd seccomp and apparmor templates, it looks like unix sockets are enabled by default. To work out what was needed, I created a test snap that binds and accepts connections on a network socket and unix socket. With no network-bind interface connected, the network socket would fail on permission denied while the unix socket would fail on “operation not permitted”.
So, I manually changed the seccomp policy of the test snap to simply add:
bind
listen
accept
accept4
and recompile. When restarting the snap, the network socket would still fail while the unix socket started up fine.
Does this seem like a reasonable approach? Am I missing anything? Would the snapd team support the addition of a new interface of say unix-bind where unix sockets work but not network sockets. Using network-bind would still allow both types to work. If there are no objections, I could make a PR to add this.
