/dev/ashmem and /dev/binder not usable inside confinement

Bug #1647168 reported by Simon Fels
6
This bug affects 1 person
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/container-manager

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.

Simon Fels (morphis)
description: updated
Simon Fels (morphis)
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.