I’ve just made a snap of bandwhich which is a command line utility for monitoring things that use network bandwidth - a bit like nethogs.
I’ve specified network, network-observe and system-observe but it’s still unable to work. The application reports as follows (even when run with sudo which is typically required anyway).
$ sudo bandwhich -i wlp3s0
Error:
Insufficient permissions to listen on network interface(s). You can work around
this issue like this:
* Try running `bandwhich` with `sudo`
* Build a `setcap(8)` wrapper for `bandwhich` with the following rules:
`cap_net_raw,cap_net_admin+ep`
I think this probably needs an addition to the network interface to allow raw sockets. Similar to how I added write support to the optical-drive interface. It would then be an optional extra that the store can assert for snaps that absolutely require it, and opt-in for other snaps if the user decides to allow it.
= AppArmor =
Time: Jan 15 15:39:17
Log: apparmor="DENIED" operation="capable" profile="snap.bandwhich.bandwhich" pid=2357930 comm="display_handler" capability=2 capname="dac_read_search"
Capability: dac_read_search
Suggestions:
* adjust program to not require 'CAP_DAC_READ_SEARCH' (see 'man 7 capabilities')
* do nothing if program otherwise works properly
So when confined it can’t identify processes owning traffic (even though it has process-control) and also seems to be failing to do dns lookups, as the remote address lookup fails too.
Just as a test to see if dac_read_search is all you need to get it to work, you could try adding either greengrass-support or system-backup interfaces, though I don’t think either of these interfaces should really be used with your snap as your snap is neither greengrass nor does it seem to be backing anything up.
system-backup is unknown here on 2.42. greengrass-support worked. What’s the next step, if that worked, do we need to find specifically what in that interface worked?
Ah yes, I think that’s a 2.43 thing. If you wanted you could try refresh to snapd/core beta channel.
You could try disconnecting the greengrass-support interface and adding the following snippet to your apparmor profile for your snap:
capability dac_read_search,
(putting it within the braces). The apparmor profile would be located at /var/lib/snapd/apparmor/profiles/snap.<snap-name>.<app-name>. After editing, reload it with:
and then re-launch your application and see if it works.
I did just notice that another slightly weird interface that might be more acceptable for your application to use is the home interface with the read: all attribute specified. But first try just adding the above snippet to your profile, then if it does work with just that capability line added, try removing that line and connecting the home interface with the read: all attribute specified (IIRC the home interface won’t auto-connect with read: all specified and will need a store assertion to auto-connect).
$ cat /sys/fs/cgroup/devices/snap.bandwhich.bandwhich/devices.list
c 1:3 rwm
c 1:7 rwm
c 1:5 rwm
c 1:8 rwm
c 1:9 rwm
c 5:0 rwm
c 5:1 rwm
c 5:2 rwm
c 136:* rwm
c 137:* rwm
c 138:* rwm
c 139:* rwm
c 140:* rwm
c 141:* rwm
c 142:* rwm
c 143:* rwm
c 10:239 rwm
c 10:242 rwm
c 10:200 rwm
So try adding the capability snippet from before, re-load the apparmor profile, then run the program, and while the program is running, try doing this:
I am seeing processes owned by root in the process list (like sshd) but not my own chrome browser (which is using bandwidth as I am on a call. Chrome (and other user processes) show up in the unconfined bandwhich. The dns lookups also don’t work.
I think creating a socket is a different operation from creating a raw socket. It feels like network should not allow you to create raw sockets. Perhaps a new interface or an option on the network interface.
