Uuidd apparmor denial

sparkiegeek · March 16, 2020, 11:25am

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:

ROS based snap also hit it
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?

ack · March 16, 2020, 11:31am

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

github.com

karelzak/util-linux/blob/master/libuuid/src/uuidd.h#L43-L49


#define UUIDD_OP_GETPID			0
#define UUIDD_OP_GET_MAXOP		1
#define UUIDD_OP_TIME_UUID		2
#define UUIDD_OP_RANDOM_UUID		3
#define UUIDD_OP_BULK_TIME_UUID		4
#define UUIDD_OP_BULK_RANDOM_UUID	5
#define UUIDD_MAX_OP			UUIDD_OP_BULK_RANDOM_UUID

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.

ack · March 16, 2020, 11:44am

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

jdstrand · March 16, 2020, 12:13pm

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.