Apparmor denied issues

Hello ,

I am getting below AppArmor denied issue while checking using “snappy-debug”:

Log: apparmor=“DENIED” operation=“open” profile=“snap.lenovo-wwan-dpr.wwan-dpr” name="/dev/wwan0at1" pid=4117 comm=“FccUnlock” requested_mask=“wr” denied_mask=“wr” fsuid=0 ouid=0 File: /dev/wwan0at1 (write)

Do , i need to add any plugs for this ? Any information regarding this will be helpful.

Thank you !!

As per apparmor issue , “/dev/wwan0at1” is not accessible by snap . Hence , i have modified like below and it looks working . Also , i need to connect like “snap connect lenovo-wwan-dpr:test”

plugs:  
  test:
    interface: system-files
    read:
      - /dev/wwan0at1
    write:
      - /dev/wwan0at1

Is this the correct way to solve this issue ? Also , do i need to request auto-connect for new plug “test” as mentioned above ? Any information regarding this will be helpful.

Thank you

Any information regarding above comment will be helpful. Thank you in advance.

Hi @nitin_exclusively - so it is possible to access /dev/wwan0at1 if your snap slots the modem-manager interface - however, this is really only designed for the modem-manager snap itself. Can you explain why your snap requires access to the wwan device directly? I recall it already plugs the modem-manager interface which gives it access to ModemManager (which in turn has raw access to the wwan device). Is this not sufficient for your snap? Thanks.

Hello @alexmurray Thank you for your reply.

Device /dev/wwan0at1 is the generic AT interface and this will be passed from “lenovo-wwan-dpr” App to perform FCC unlock functionality . We are using “AT” interface to perform FCC unlock and connect to network, for some WWAN module.

I recall it already plugs the modem-manager interface which gives it access to ModemManager

Yes, we already plugs “modem-manager” plugs . I might be wrong , but i think “modem-manager” interface give access to “/dev/wwan0mbim0” as we had used this device for some modem and didnt get this issue but now when we pass “/dev/wwan0at1” then we get this access issue .

Thank you

Snap interfaces can either be ‘plugged’ or ‘slotted’ - when slotting an interface this semantically maps to providing that interface to other snaps - and so when plugging an interface then you are connecting to the slot of another snap (or an implicit slot in the case of slots provided by the core snap/system).

You can see the various things that an interface is granted by looking at the snapd source code - when you slot the modem-manager interface you get the rules defined in https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L47 and https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L146.

If instead you plug the modem-manager interface you get the rules in https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L179 and https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L212

Note I am only focussing on the AppArmor rules but the process is similar for seccomp and udev rules as well.

As such, we can see that /dev/wwan devices are only allowed access within the slot rules - https://github.com/snapcore/snapd/blob/fc63ca9480f93b261db0816e08db9246f976ccaf/interfaces/builtin/modem_manager.go#L64 - and so your snap will then instead need to slot this interface instead. However, given the semantics I described above, ideally then your snap would actually also ship modem-manager itself internally and provide a complete implementation of the modem-manager slot.

I am not certain what the best course of action is here - it doesn’t really feel right to slot modem-manager as your snap is not trying to be a complete implementation of modem-manager on a system (and instead it uses the system installed ModemManager which does seem most appropriate).

Also for the case of just plug-ing modem-manager - whilst we can use system-files to grant AppArmor access to the device file in this case, this will not grant the appropriate udev rules for device to be visible within the snap’s device cgroup.

@mvo @pedronis @abeato @ogra any ideas on what might be most appropriate here? Am I missing something obvious (or non-obvious)?

@alexmurray Thank you for this information. I got information regarding slot and i tried adding only ‘modem-manager’ slots in my snap but unfortunately , it did not fix this issue, maybe because we don’t have this modem-manager implementation in my snap.

I have tried using system-files as per example which i had shown earlier and this seems to fix the issue and its works fine. Hence ,for this issue, i would like to avoid shipping “modem-manager” from the snap.

May i know, if its acceptable to use system-files as below to fx this issue ?

plugs:  
  test:
    interface: system-files
    read:
      - /dev/wwan0at1
    write:
      - /dev/wwan0at1

Thank you

no, system-files only allows access to actual files, not to devices, as alex said, it will miss the udev rules to make the device accessible inside the snaps cgroup …

Thank you for this information.

not to devices, as alex said, miss the udev rules to make the device accessible inside the snaps cgroup

OK, Noted but i was just wondering, why i didn’t get any issue when i use “system-files” . I will do some more testing to find , if there is any issue regarding udev rules.

However, It will be helpful, if you can provide your suggestion to fix this issue ?

Thank you !!

I have retested again using system-files and it works fine … It looks only access to file “/dev/wwan0at1” works … didnt face any issue regarding udev rules in test snap i.e stric confined which i have created for this .

@ogra @alexmurray Any comment regarding this will be helpful !! Thank you

Did you get it working with only the system-files interface or are you slotting modem-manager as well?

@pmeulengracht Thank you for your comments !! I get it working only using system-files . But in this case i need to explicitly request approval for plug “test” like below :

plugs:
test:
interface: system-files
read:
- /dev/wwan0at1
write:
- /dev/wwan0at1

Is my understanding correct ?