/dev/ashmem and /dev/binder not usable inside confinement
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snap-confine (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
I have a snap which starts an entire Android system in a LXC container similar to how we do it on Ubuntu Touch. The LXC container itself works fine in devmode, confinement is not yet considered and left completely aside.
The Android system needs access to the two nodes /dev/ashmem and /dev/binder from the host system. They are both available in the snap execution environment and are bind mounted into the LXC container environment. Inside the container both nodes are accessible and can be used.
However certain mmap calls to memory allocated via /dev/ashmem fail with a permission denied error and also binder IPC calls fail. These problems are not occurring when the LXC container is started outside of the snap execution environment, so it can be already ruled out as a problem here. The container configuration is also the same.
The problem can be fixed by executing the container management process via
$ aa-exec -p unconfined -- $SNAP/bin/
which then uses liblxc to start the container.
I don't really understand why this is required as AppArmor shouldn't prevent any use of /dev/ashmem or /dev/binder when the snap is installed with --devmode and dmesg doesn't show any denials, just that it allows all calls.
This is with snap-confine 1.0.43 on Ubuntu 16.04
I am opening this bug here to start tracking the problem and get some more visibility and thoughts from others.