Classic confinement request for the 'glucometerutils' snap

store-requests
#1

Hi,

I have created a snap package (my first ever!) for the glucometerutils tool written in Python. The snapcraft.yaml file is in this git repository. The tool requires access to various files under /dev including but not limited to block devices, hid devices, serial, scsi devices etc. (see https://github.com/glucometers-tech/glucometerutils#supported-devices for more details).

I own two of the supported glucometers and one of those requires access to a hid device and the other requires access to a block device corresponding to the connected device - on my computer, it was /dev/sda . I tried using the hidraw interface to get access to the first device. I found out that I cannot pre-declare the path to the hid device (as documented in https://snapcraft.io/docs/hidraw-interface) because I cannot predict the name of the hid device that will be created for the connected glucometer on each of the users’ computers. So the snap package will not be able to access the device.

So I have currently configured the snap to be a classic snap. And as per the documented process, I am requesting approval for it.

Please let me know if there are any concerns with this request or if you need any additional information from me to process this request.

#2

as a trusted bystander (not a reviewer so I can’t vote on this) I can’t see any way with the current interfaces we have available for you to achieve strict confinement with your app yet. Therefore I encourage the reviewers to approve this with a view to getting it converted to strict confinement after appropriate interface improvements are made to snapd.

To that end, @guruprasad, it might be useful to post details of how your app interfaces with the glucometers in a launchpad bug at https://bugs.launchpad.net/snapd with a request for interface improvements or additions to support your usecase so that you can switch to strict confinement in the distant future.

1 Like
#3

Is there anything specific that I need to do to get this request reviewed? Asking because it has nearly been 2 months since I posted this request.

Not sure if things are blocked on this or if it is just a good-to-have thing.

#4

I think this must have got lost in the summer period while several folk were taking vacations… @reviewers pinging you to have a peek here :slight_smile:

#5

This situation is explicitly called out as an unsupported reason for use of classic.

1 Like
#6

@kyrofa, can you please indicate which unsupported use case you’re referring to on the list? It will help the author to understand why, rather than a nebulous “it’s not supported” message. This is something that should be done in all cases, not just this thread.

#7

“difficulty making strict confinement work”.

In general, classic confinement is intended for software that by design isn’t useful without classic. This includes specific categories of software: compilers, IDEs, and more outlined in the link above. Difficulty getting one’s software working under strict confinement, or otherwise wanting to use classic as a “bridge” to strict, is in my experience not really the intended use-case for classic confinement.

1 Like
#8

Hi @guruprasad apologize for the delay, and thanks @kyrofa for your feedback, its very nice to “read” you around :).

As @kyrofa mentioned, we have a process to grant classic and the snaps that are granted such confinement should belong to one of the supported categories. In this case, I believe we still need more information to proceed.

Have you tried plugging the-block-devices-interface (as per the iface code it should allow you access to the raw devices https://github.com/snapcore/snapd/blob/master/interfaces/builtin/block_devices.go#L61), the-scsi-generic-interface and others related from the supported interfaces ? I suggest you experiment with those, use snappy-debug (that will suggest interfaces based on your snap behavior) and see if glucometerutils can stay under strict confinement. If you still see issues, free to come back here and share the denials in case we can keep exploring alternatives.

1 Like
#9

@guruprasad - ping, can you please provide the requested information?

#10

@emitorino, @pfsmorigo, sorry for the very late response. I have been very busy with my personal life and haven’t had the time to check and get back to you on this. I hope to do this in the coming week.

1 Like
#11

@emitorino, the source for this snap package is on Launchpad and you can view the snapcraft.yaml file here.

As you can see there, the application already lists the following interfaces:

    plugs:
      - block-devices
      - hidraw
      - raw-input
      - raw-usb
      - removable-media
      - scsi-generic
      - serial-port

And with the classic confinement mode turned off and all these interfaces configured, the snap is unable to access the hidraw device corresponding to my FreeStyle Libre glucometer.

Like I mentioned in my initial post in this discussion,

I am unable to access a /dev/hidrawX device from the snap unless it is running in the classic confinement mode.

Below are the log lines from the snappy-debug tool corresponding to this issue.

= Seccomp =
Time: Dec  2 17:37:14
Log: auid=1000 uid=0 gid=0 ses=4 subj=snap.glucometerutils.glucometer pid=794673 comm="python" exe="/snap/glucometerutils/x2/usr/bin/python3.8" sig=0 arch=c000003e 41(socket) compat=0 ip=0x7fc05bd237ab code=0x50000
Syscall: socket
Suggestions:
* add account-control (if using NETLINK_AUDIT)
* add audio-playback (if using NETLINK_KOBJECT_UEVENT)
* add bluetooth-control (if using AF_{ALG,BLUETOOTH})
* add firewall-control (if using NETLINK_{FIREWALL,IP6_FW,NETFILTER,NF_LOG,ROUTE})
* add hardware-observe (if using NETLINK_{GENERIC,KOBJECT_UEVENT})
* add netlink-audit (if using NETLINK_AUDIT)
* add netlink-connector (if using NETLINK_CONNECTOR)
* add network (if using AF_INET{,6}, AF_CONN, NETLINK_ROUTE)
* add network-bind (if using AF_INET{,6}, NETLINK_ROUTE)
* add network-control (if using AF_{APPLETALK,BRIDGE,INET,INET6,IPX,PACKET,PPPOX,SNA}, NETLINK_{DNRTMSG,FIB_LOOKUP,GENERIC,INET_DIAG,ISCSI,KOBJECT_UEVENT,RDMA,ROUTE,XFRM})
* add network-observe (if using SOCK_RAW, AF_INET{,6}), NETLINK_{GENERIC,INET_DIAG,KOBJECT_UEVENT,ROUTE})
* add raw-usb (if using NETLINK_KOBJECT_UEVENT)
* add time-control (if using NETLINK_AUDIT)
* add unity7 (if using NETLINK_KOBJECT_UEVENT)
* add x11 (if using NETLINK_KOBJECT_UEVENT)

The other glucometer that I have is accessible via the /dev/sda device and with strict confinement I get a permission denied error. The logs in snappy-debug corresponding to this error are:

= AppArmor =
Time: Dec  2 17:40:40
Log: apparmor="DENIED" operation="open" class="file" profile="snap.glucometerutils.glucometer" name="/dev/sda" pid=795793 comm="python" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0

Various glucometers supported by the glucometerutils tool are accessed via various device file types and names and I do not know if there is a proper way to allow accessing all of those.

So that is why I thought that the classic confinement mode is necessary for this snap application, but I might be wrong because of having misunderstood something here.

Please advise on what I should do here.

Thanks in advance!

CC @pfsmorigo