I was wondering if any of the socket related declarations for daemons in snapcraft.yaml might address this? (The docs are rather terse with no examples.)
This nodejs snap does have multiple nodejs daemons. Currently the snapcraft only declares one, the controller, and it starts the others (in nodejs, not mentioned yet in snapcraft.yaml). The current plan though is to declare them all explicitly as daemons in snapcraft.yaml, where the controlled daemons are disabled (via install hook), then started manually by the controller. Would this level of visibility in snapcraft.yaml open the door to using socket related declarations to resolve this?
By the way, the bluetooth-control interface does eliminate the DENIED too, but it seems like a poor match for this case, which does not involve BT. https://bugs.launchpad.net/snappy/+bug/1613572
Probably we want a new specific interface just for accessing the kernel crypto functions here. Can you provide some more details about what kinds of kernel crypto functions your application uses (or perhaps a high level explanation of what the application is doing that needs kernel crypto functions)? The fact that this is a NodeJS daemon isn’t really relevant, I don’t think there’s anything intrinsic to being implemented in NodeJS that requires kernel crypto functions
See https://www.kernel.org/doc/html/v4.10/crypto/index.html for example of what that API looks like. If you don’t know why your application uses this, could you maybe provide details on what packages the application uses and we start there?
@jdstrand WDYT about a (strawman) kernel-crypto-control interface which (for now) just has apparmor for:
network alg seqpacket,
which doesn’t auto-connect and is intended to be used with network-bind and network? I don’t think it makes sense to add this to network-control (maybe it does?), but then again maybe there is not a large attack surface exposed by this kernel crypto function API and it could be put in an already existing and less privileged interface?
I read https://www.kernel.org/doc/html/v4.10/crypto/userspace-if.html and adding a new interface seems to make sense OTOH, though I’d probably want others from the security team (eg, @alexmurray or perhaps Chris or John) to review the concept. We currently won’t be able to mediate the sockaddr data structure in a fine-grained manner though, so it would be all or nothing. We’d also need to verify if AF_ALG can’t be used for anything else.
I’m not sure kernel-crypto-*control* is right since we aren’t controlling anything AFAICS in the userspace docs; we’re just accessing crypt functionality.
Also, I would want this to be standalone from network* since it should be required that a command that uses AF_ALG need network access. This would likely need some additional seccomp policy (or possibly apparmor).
I’ve taken a TODO to look at this, but it is currently not roadmapped.