on your classic install (desktop) the network-manager interface backend is provided through the installed network-manager deb … while ubuntu core requires you to install the network-manager snap … that is what causes the name difference (not sure but there might also be a functional difference here)
It looks like there is a security denial. Please do this at the time of the error:
$ grep audit /var/log/syslog
and paste them here.
Apr 18 21:32:57 caracalla kernel: [1658598.417295] audit: type=1400 audit(1492551177.653:1522): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.core.hook.configure" pid=1121 comm="apparmor_parser"
Apr 18 21:32:57 caracalla kernel: [1658598.486594] audit: type=1400 audit(1492551177.721:1523): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.network-manager.hook.configure" pid=1123 comm="apparmor_parser"
Apr 18 21:32:58 caracalla kernel: [1658599.096993] audit: type=1400 audit(1492551178.333:1524): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.network-manager.networkmanager" pid=1125 comm="apparmor_parser"
Apr 18 21:32:58 caracalla kernel: [1658599.145652] audit: type=1400 audit(1492551178.381:1525): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.network-manager.nmcli" pid=1127 comm="apparmor_parser"
Apr 18 21:33:05 caracalla kernel: [1658606.208469] audit: type=1400 audit(1492551185.437:1526): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.machineshop-edge.nmcli" pid=1138 comm="apparmor_parser"
Apr 18 21:33:06 caracalla kernel: [1658606.790070] audit: type=1400 audit(1492551186.017:1527): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.machineshop-edge.service" pid=1140 comm="apparmor_parser"
Apr 18 21:33:10 caracalla kernel: [1658611.634222] audit: type=1107 audit(1492551190.857:1528): pid=1376 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" name=":1.45" mask="receive" pid=1578 label="snap.network-manager.networkmanager" peer_pid=1200 peer_label="snap.machineshop-edge.service"
Apr 18 21:33:38 caracalla kernel: [1658638.829121] audit: type=1400 audit(1492551218.028:1529): apparmor="DENIED" operation="capable" profile="snap.machineshop-edge.service" pid=1214 comm="ifconfig" capability=16 capname="sys_module"
This is the denial that is causing trouble. This access is currently allowed in networkManagerConnectedSlotAppArmor via this rule:
# Allow traffic to/from our DBus path
dbus (receive, send)
bus=system
path=/org/freedesktop/NetworkManager{,/**}
peer=(label=###PLUG_SECURITY_TAGS###),
Can you look to see if this rule is in /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager:
# Allow traffic to/from our DBus path
dbus (receive, send)
bus=system
path=/org/freedesktop/NetworkManager{,/**}
peer=(label="snap.machineshop-edge.service"),
I suspect that at the time of access the security policy doesn’t contain this rule. This could be a result of nmcli running before you have manually connected the interfaces. Can you verify that the interfaces are connected with ‘snap interfaces’ and then run nmcli (and report any security policy denials).
If the interfaces show they are connected but the above rule isn’t in your policy, then that would indicate there is a bug in the interface connection code.
It’s working as expected now. The required network-manager interface was connected to my snap’s network-manager interface (see previous post), but I tried disconnecting from the network-manager:service slot then re-connecting it, and now it’s working.
On another note, is there any way to auto-connect this interface instead of having the user who installs my snap have to do so? Or are there plans for a permissions/interfaces request prompt when a user installs a snap (similar to Android) so they can be auto-connected at that time?
Hmm, if it was connected but not allowed and disconnecting/connecting fixed it, that still might indicate a bug. If you can find a reliable reproducer where snap interfaces shows it is connected but the access is still denied, please report it.
For some ‘plugs’, the base declaration deliberately makes it so these interfaces require a manual connection, usually because the interface grants privileged access to the system. https://github.com/snapcore/snapd/wiki/Interfaces gives some high-level details for each interface and whether auto-connection happens or not and why. Keep in mind, interfaces are manually connected for a reason and the user installing the snap should have a say on whether the interface should be connected. This keeps the ecosystem secure and maintains the public store’s reputation.
The snap declaration mechanism exists to override the base declaration and allow auto-connection and store reviewers may issue a snap declaration through the store. Issuing a snap declaration in this manner requires trust in the snap’s publisher because it removes the user’s choice during the install process and essentially having the brand (ie, public store or private brand store) vouch for the snap publisher. If your snap is in a brand store, then the brand owner can issue snap declarations for your brand (since vouching for your own software makes a lot of sense :).
As for prompting on install to honor the user’s input and making it easier, I believe that this is planned, though IMO we want to be careful about introducing click-through security prompts like those that plagued Android over the years (indeed, they are trying to move away from them).
1 Like
Will do. I’ll definitely report the bug if I can re-produce the issue reliably.
Ah OK, that may be an option for our situation. I will ask our HW partners if they plan on hosting a private brand store.
Thank you all for your help!
@rmn87 Hi, I have been following a path similar to yours.
(Use of nmcli from inside a snap)
I am trying to use nmcli from inside my snap (which basically is a java application).
I have successfully the nmcli binary into my snap and also made the network-manager connection.
I am still getting an error returned from nmcli con show from inside the snap. The guys on the forum have confirmed that I have no security issues so it should be all fine.
Did you also run nmcli as root as someone suggested or can you recall anything else that had to be fixed?
Thanks.
Can you give us the exact output you get from nmcli?
I have resolved my issues now. It was to do with the connection id being incorrectly parsed (i.e. a problem in the java code).
Thanks for your help.
To connect the network interface you need to run the command “snap connect SNAPNAME:network-manager network-manager:service” in Ubuntu Core!
1 Like
Can anyone explain to me WHY does snapcraft need to bundle the network-manager binary with my snap package, even though all I need is to execute nmcli command on the target machine?
The resulting snap package is some 22 MB, even though my actual stuff is tiny.
Thanks!
the network-manager interface only allows access to network-managers dbus (for added security i belive, @jdstrand might have deeper insight), while you could indeed poke dbus directly from your snap shipping nmcli is more convenient … note though that you dont need to ship the full network manager package, you could as well write a part that singles out the nmcli command only, runs an ldd on it and makes sure the correct libs to run it are included in your snap, i guess that would be significantly smaller.
@ogra, that assumption still valid? We are working in a project we started developing under classic Ubuntu Server 20.04.01 for armhf while we are preparing our images to migrate to Core, but we are having serious problems using snap based Network-Manager, suddenly I saw your comments here, which sync with what I have been seeing using Network-Manager deb on Classic, so, Is it true, classic should relay on network-manager deb if we need to talk to network-manager from inside our application confinement (DBUS or nmcli )?
i actually believe both should work (NM deb as well as snap) on classic … from inside your snap env you will only be able to talk through dbus to the outside world, i do not think anything changed in the network-manager interface in that regard, so yes, it is still direct dbus calls or using nmcli (which actually just acts as frontend to dbus here).
@ogra, thanks for your reply, on classic, we are not able to talk to Network-Manager snap, always getting the “AppArmour” denying, although if I try Network-Manager deb it works fine. I am having the following plugins, do you thing anything is missing? We also are talking with modem-manager with no problem at all, only network-manager is being denied.
plugs:
- network-control
- firewall-control
- network-bind
- network-manager
- network-setup-control
- hardware-observe
- network-setup-observe
- network-observe
- ppplets ask @abeato (as the NM specialist here) if this is supposed to work then …
do you have the deb still installed when trying with the snap or do you cleanly remove it ?
All tests were done in a clear image, no network-manager deb install, we later on installed to check the results and re-flashed back the unite. But what really called my attention was the fact that AppArmor Network Manager has the lines for accessing NetworkManager1 and ObjectManager and they seams to be denied by the AppArmor:
AppArmor network-manager profile
`# Allow traffic to/from our DBus path
dbus (receive, send)
bus=system
path=/org/freedesktop/NetworkManager{,/**}
peer=(label=“snap.xxx-application.{ModemProxy,nmcli}”),
# Later versions of NetworkManager implement org.freedesktop.DBus.ObjectManager
# for clients to easily obtain all (and be alerted to added/removed) objects
# from the service.
dbus (receive, send)
bus=system
path=/org/freedesktop
interface=org.freedesktop.DBus.ObjectManager
peer=(label=“snap.xxx-application.{ModemProxy,nmcli}”),
`
Execution from the xxx-application.nmcli
Apr 13 08:56:15 ubuntu kernel: audit: type=1326 audit(1618304175.467:785): auid=1000 uid=0 gid=0 ses=5 pid=24647 comm="nmcli" exe="/snap/xxx-application/x3/bin/nmcli" sig=0 arch=40000028 syscall=380 compat=0 ip=0xb6b5c692 code=0x50000 Apr 13 08:56:15 ubuntu audit[1549]: USER_AVC pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name=":1.62" pid=24647 label="snap.xxx-application.nmcli" peer_pid=24175 peer_label="snap.network-manager.networkmanager" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu audit[1549]: USER_AVC pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" name=":1.75" mask="receive" pid=24175 label="snap.network-manager.networkmanager" peer_pid=24647 peer_label="snap.xxx-application.nmcli" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu kernel: audit: type=1107 audit(1618304175.479:786): pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name=":1.62" pid=24647 label="snap.xxx-application.nmcli" peer_pid=24175 peer_label="snap.network-manager.networkmanager" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu kernel: audit: type=1107 audit(1618304175.479:787): pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" name=":1.75" mask="receive" pid=24175 label="snap.network-manager.networkmanager" peer_pid=24647 peer_label="snap.xxx-application.nmcli" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu kernel: audit: type=1107 audit(1618304175.479:788): pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="GetPermissions" mask="send" name=":1.62" pid=24647 label="snap.xxx-application.nmcli" peer_pid=24175 peer_label="snap.network-manager.networkmanager" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu audit[1549]: USER_AVC pid=1549 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="GetPermissions" mask="send" name=":1.62" pid=24647 label="snap.xxx-application.nmcli" peer_pid=24175 peer_label="snap.network-manager.networkmanager" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' Apr 13 08:56:15 ubuntu systemd[1]: snap.xxx-application.nmcli.6071dd25-5f8f-4419-a4ed-2ccd6db40747.scope: Succeeded. Apr 13 08:56:15 ubuntu sudo[24643]: pam_unix(sudo:session): session closed for user root Apr 13 08:56:44 ubuntu sudo[24677]: avnet : TTY=pts/0 ; PWD=/home/avnet ; USER=root ; COMMAND=/usr/bin/vi /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager Apr 13 08:56:44 ubuntu sudo[24677]: pam_unix(sudo:session): session opened for user root by avnet(uid=0)
I added nmcli to create a example to demonstrate our error, even though there is a clear session on Network-Manager on Classic Ubuntu, our application is not being able to communicate. Although, the same is not true on core, soon as I connect to network-manager:service everything starts to work.
About out application, we have a brand store and app with strict confinement.
Thanks in advance,
what is snap connections xxx-application in both cases ?