Anyone know which if any interface gets rid of this, if any:
AVC apparmor="DENIED" operation="create" profile="snap.mysnap.myservice" pid=11543 comm="node" family="alg" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create
network, network-bind and network-control are connected.
This is a nodejs snap (therefore comm=“node”, I think).
did snappy-debug give any hints in “recommend mode” ?
I don’t think we have an interface for this. Can you try adding the following to:
network alg seqpacket,
to the file /var/lib/snapd/apparmor/profiles/snap.mysnap.myservice (before the last }) and then run:
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.mysnap.myservice
and see if your service works now?
Yes, that does eliminate the DENIED.
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?
I don’t see any hints:
$ sudo journalctl --output=short --follow --all | sudo snappy-debug --recommend
kernel.printk_ratelimit = 0
= AppArmor =
Time: Mar 06 15:12:31
Log: apparmor="DENIED" operation="create" profile="mysnap.myapp" pid=20110 comm="node" family="alg" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create"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
It now appears that root cause of the DENIED is the code performing calls to the kernel crypto API, a required function.
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?
What @ijohnson said would seem to cover the common use cases.
As referenced in the Kernel Crypto Userspace API documentation, specifically the https://www.kernel.org/doc/html/v4.10/crypto/userspace-if.html#symmetric-cipher-api functions would be essential.
We would like the capability to create, close, read from, and write to afg family sockets
@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.