Requesting multiple auto-connects for snap "ausweisapp2-ce"


#1

Hello,

i’m requesting the following auto-connects for the snap “ausweisapp2-ce”:

For the included “pcsc-lite”-daemon:

  1. hardware-observe
  2. raw-usb

Both are needed that the card-daemon can find and use connected USB-based card-readers.

For the actual application “ausweisapp2”:

  1. hardware-observe
  2. network-manager
  3. network-observe

The first one is needed for the same reason as the card-reader (Possibly a duplicate entry which is not needed). The other two are needed because “AusweisApp2” can use an Android-smartphone as a NFC-reader which runs the same app. The desktop app uses D-BUS to communicate with NetworkManager and opens a its own (private) connection to the smartphone.

I’m only the packager of the snap. I’m using the openly available code from Github, make some small modifications (Removing debug-messages spamming the log, using the correct directories under Linux-distributions).


#2

Is the Android-smartphone functionality core to the functionality of the snap? The network-manager interface provides full network configuration of the device and is therefore quite powerful.

+1 for auto-connecting hardware-observve and network-observe

As for raw-usb, can you put your snap in devmode, connect all of the interfaces except raw-usb, exercise the snap with a USB card reader and post back any policy violations for the snap that are logged to journalctl?


#3

Here is the deny message when not connecting “raw-usb”:

[ 3100.309208] audit: type=1400 audit(1553077613.541:478): apparmor=“DENIED” operation=“open” profile=“snap.ausweisapp2-ce.pcscd” name="/dev/bus/usb/001/006" pid=10019 comm=“pcscd” requested_mask=“wr” denied_mask=“wr” fsuid=0 ouid=0

The “pcsc-lite”-daemon needs read/write-access to the card reader. It uses “libusb” to access the devices.

Here is also the log for “NetworkManager”-access:

[ 3423.194345] audit: type=1107 audit(1553077936.424:494): pid=789 uid=103 auid=4294967295 ses=4294967295 subj==unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.NetworkManager" pid=10642 label="snap.ausweisapp2-ce.ausweisapp2-ce" peer_pid=4952 peer_label="unconfined"

Connecting to Android-smartphones is a core functionality of the application. Not everyone has a USB-card-reader and most Android-devices provide an NFC-card-reader which can be used be the desktop-application. If it is possible to use another interface i would be happy to use.

Edit:

I’ve tested using the interface “network-manager-observe”. This is sufficient for running the application. Connecting to a Android-smartphone works flawlessly. So “network-manager” is not needed. I’ve already uploaded a fixed version for building.


#4

@jdstrand:

Any news on my request?


#5

@pstolowski - can you comment on if dynamic hotplug can help remove the need for raw-usb today and if not, what is needed going forward?


#6

Hotplug is not going to magically eliminate the need for raw-usb; it is just a framework where we can enhance existing interfaces or implement new ones in a way where their slots:

  • are created automatically as devices appear in the system, and removed when device is unplugged.
  • have precise permissions (the slot has access to the specific device, and not the entire family of devices like e.g. with cameras right now) and support multiple slots of same interface type if multiple instances of a device are present.
  • are remembered and recognized (based on some key attributes, e.g. a serial number) as device is unplugged/plugged back under different paths, so security profiles of existing connections are recreated if affected by change in device path.

With this new framework, which does all the above (almost) transparently for the interfaces, we still need to think about concrete interfaces and what are their required permissions assuming they are given a datailed info about a device under hotplug framework. In other words, and to be more specific:

  • we might need a new “card reader” interface and make it hotplug-aware (see below for what that means).
  • determine what is the udev event data reported when that device is plugged (card is inserted). This can be found by running udevadm monitor -p - we are looking for an event relevant for given device class, that carries a path under /dev… that we’re interested in for out slot(s).
  • with the above, the new (or existing) interface needs to implement the new HotplugDeviceDetected(deviceInfo *hotplug.HotplugDeviceInfo) (*hotplug.ProposedSlot, error) function of the interface: its job is to decide if given device is relevant for this interface (by filtering out on udev attributes that we determined with help of udevadm), and if so - create a definiton of “proposed” slot, which in most cases is to simply set a "path":"/dev/..." attribute on it. This slot is later a subject of general Connected methods of the interface code, so this path attribute can be used to create a precise profile.

That’s more less what I think would be needed. It’s case-by-case and interface-by-interface work that will happen over time. The first interface to benefit from it is serial-port (PR is ready and about to land).


#7

Thanks @pstolowski, I knew the new work didn’t magically fix everything but wasn’t sure of the status and next steps for something like this.

+1 to auto-connect raw-usb for now. I already gave a +1 for hardware-observe and network-observe.

That leaves network-manager-observe. I’ve already voted for network-observe and network-manager-observe doesn’t give much beyond that, so +1.

@reviewers - can one/all of you cast your votes for auto-connecting raw-usb, hardware-observe, network-observe and network-manager-observe?


#8

@glasen77 - not sure if you are interested in furthering snapd and helping with a new “card reader” interface, but if you are, responding to @pstolowski’s feedback would be the next step (that is not required to process this request of course). :slight_smile:


#9

@jdstrand - Thank you for the permissions.

Just one last question:

When will the interface “network-manager-observe” be available on the build service? “snapd 2.38” is in the proposed-repos of Xenial, Bionic and above. At the moment the deployment of my snap fails when using this interface.

Regarding the new interface:

At the moment i’m writing my master thesis in bioinformatics and i don’t know if i will have enough spare time for another task.


#10

+1 from me for raw-usb, hardware-observe, network-observe and network-manager-observe


#11

Based on the feedback, I am :+1: on raw-usb, hardware-observe , network-observe and network-manager-observe.


#12

Note that on Ubuntu, snapd uses a feature called ‘re-exec’ where the distro package will check to see if there is a newer version of the core/snapd snap available than itself, and if there is, will use its snapd instead of the deb’s. You can always see what is available on your system with: snap version. The current core snap is at 2.38 in the stable channel, so you should be fine (the deb version is on its way, as you mentioned).


#13

3 votes for, 0 against for auto-connecting all of raw-usb, hardware-observe, network-observe and network-manager-observe. This is now live*

  • note that the review-tools in production in the store doesn’t yet have the 2.38 interfaces so the snap will not pass automated review. I will keep an eye for new revisions and manually approve them in the meantime.