Public bug reported:

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.

I am opening this bug here to start tracking the problem and get some
more visibility and thoughts from others.

** Affects: snap-confine (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  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.
+ with --devmode and dmesg doesn't show any denials, just that it allows
+ all calls.
  
  I am opening this bug here to start tracking the problem and get some
  more visibility and thoughts from others.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1647168

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1647168/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to