Uuidd apparmor denial

The MAAS snap currently reports lots of apparmor denials for rw on /run/uuidd/request see LP #1867571 for info.

Tracking this down it appears to be Python’s uuid.uuid1() implementation, which is in turn using libuuid. That requests rw access to uuidd which is running on the host, listening on /run/uuidd/request.

As this is Python stdlib, MAAS is not the only snap that this denial occurs in:

  1. ROS based snap also hit it
  2. Open vSwitch support added it to avoid denials there.

In 2049f2c @jdstrand added r support, but in our tests it’s always rw that’s requested.

Could the template apparmor profile allow write access too? Or if that’s considered too broad, an interface be added to allow this?

Looking at libuuid (and uuidd) source code, it seems the socket protocol requires writing the type of the requested operation to the socket:

I’m not sure if just having read access means the current rule is not effective, as libuuid will still work properly if it can’t connect to the socket, as it falls back to generating a local random.

I just did a quick test adding a /run/uuidd/request rw, apparmor rule to the MAAS snap, and that does stop denials.

1 Like

I can confirm in https://github.com/karelzak/util-linux/blob/master/libuuid/src/gen_uuid.c#L371 there is a write and so we must use ‘rw’. I’ll submit a PR.

1 Like