| 2013-07-02 20:31:43 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2013-07-02 20:32:01 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run on a Nexus 7:
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
The read accesses are not ideal but probably ok, but the writes to /dev/nvmap and /dev/nvhost-* allow applications to attack these devices directly. I'm not sure what the solution is, but the current behavior weakens our application confinement policy. |
SDK applications need the following AppArmor policy to run on (at least) the Nexus 7:
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
The read accesses are not ideal but probably ok, but the writes to /dev/nvmap and /dev/nvhost-* allow applications to attack these devices directly. I'm not sure what the solution is, but the current behavior weakens our application confinement policy. |
|
| 2013-07-02 20:32:09 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu) |
|
| 2013-07-02 20:32:26 |
Jamie Strandboge |
tags |
|
application-confinement |
|
| 2013-09-04 02:46:15 |
Jamie Strandboge |
summary |
SDK applications require access to /dev/nv* on grouper |
SDK applications require direct access to graphics devices |
|
| 2013-09-04 02:47:01 |
Jamie Strandboge |
summary |
SDK applications require direct access to graphics devices |
SDK applications require hardware-specific direct access to graphics devices |
|
| 2013-09-04 02:54:29 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run on (at least) the Nexus 7:
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
The read accesses are not ideal but probably ok, but the writes to /dev/nvmap and /dev/nvhost-* allow applications to attack these devices directly. I'm not sure what the solution is, but the current behavior weakens our application confinement policy. |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is both a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw, |
|
| 2013-09-04 02:56:12 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu) |
|
| 2013-09-04 02:56:21 |
Jamie Strandboge |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-09-04 02:56:21 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu Saucy) |
|
| 2013-09-04 02:56:21 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu Saucy) |
|
| 2013-09-04 02:56:31 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): importance |
Undecided |
High |
|
| 2013-09-04 02:56:50 |
Jamie Strandboge |
description |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is both a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw, |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw, |
|
| 2013-09-04 02:57:14 |
Jamie Strandboge |
bug |
|
|
added subscriber Thomas Voß |
| 2013-09-04 02:57:26 |
Jamie Strandboge |
bug |
|
|
added subscriber Loïc Minier |
| 2013-09-04 03:29:08 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Saucy): status |
New |
Triaged |
|
| 2013-09-04 03:29:14 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): status |
New |
Confirmed |
|
| 2013-09-04 16:08:53 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): assignee |
|
Ubuntu Phonedations bugs (ubuntu-phonedations-bugs) |
|
| 2013-09-06 14:18:15 |
Jamie Strandboge |
description |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw, |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue in a couple of ways:
1. by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw,
2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"
which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
/dev/kgsl-3d0 rw,
This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
/etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed. |
|
| 2013-09-06 17:31:28 |
Jamie Strandboge |
description |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue in a couple of ways:
1. by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw,
2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"
which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
/dev/kgsl-3d0 rw,
This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
/etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed. |
SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:
# FIXME: Nexus7 (grouper)
/dev/nvmap rw,
/dev/nvhost-* rw,
/sys/module/nvhost/parameters/* r,
/sys/module/fuse/parameters/tegra* r,
# FIXME: Galaxy Nexus specific (maguro)
/dev/pvrsrvkm rw,
# FIXME: Nexus 4 (mako)
/dev/kgsl-3d0 rw,
/dev/ion rw,
# FIXME: Nexus 10 (manta)
/dev/mali[0-9] rw,
/dev/ion rw,
# FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
# so lets avoid that for now. Note, ~/.nv/GLCache is used unless
# __GL_SHADER_DISK_CACHE_PATH is set
/dev/nvidia[0-9] rw,
/dev/nvidiactl rw,
This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.
In the meantime, we could solve the maintenance and ports issue in a couple of ways:
1. by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
/dev/graphics/* rw,
2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"
which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
/dev/kgsl-3d0 rw,
This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
/etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed.
3. is a variation on '2' except rather than using udev RUN to generate the policy, the package that ships the udev rule will ship corresponding apparmor policy to drop into /etc/apparmor.d/abstractions/hardware/ somewhere. |
|
| 2013-09-06 20:53:02 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): assignee |
Ubuntu Phonedations bugs (ubuntu-phonedations-bugs) |
Jamie Strandboge (jdstrand) |
|
| 2013-09-06 20:53:06 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): status |
Confirmed |
Triaged |
|
| 2013-09-06 20:53:12 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Saucy): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2013-09-06 20:53:16 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Saucy): importance |
Undecided |
High |
|
| 2013-10-08 00:03:34 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/saucy-proposed/apparmor-easyprof-ubuntu |
|
| 2013-10-08 00:29:47 |
Launchpad Janitor |
apparmor-easyprof-ubuntu (Ubuntu Saucy): status |
Triaged |
Fix Released |
|
| 2013-10-11 15:41:18 |
Jamie Strandboge |
bug task deleted |
touch-preview-images |
|
|
| 2013-10-11 15:41:28 |
Jamie Strandboge |
nominated for series |
|
Ubuntu T-series |
|
| 2013-10-11 15:41:28 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu T-series) |
|
| 2013-10-11 15:41:28 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu T-series) |
|
| 2013-10-11 15:41:38 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu T-series): status |
New |
Triaged |
|
| 2013-10-11 15:41:42 |
Jamie Strandboge |
lxc-android-config (Ubuntu T-series): status |
New |
Triaged |
|
| 2013-10-11 15:41:47 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu T-series): importance |
Undecided |
Low |
|
| 2013-10-11 15:41:51 |
Jamie Strandboge |
lxc-android-config (Ubuntu T-series): importance |
Undecided |
Low |
|
| 2013-10-11 15:41:55 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): status |
Triaged |
Won't Fix |
|
| 2013-10-11 15:42:00 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2013-10-11 15:42:02 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu T-series): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2013-10-11 15:42:04 |
Jamie Strandboge |
lxc-android-config (Ubuntu T-series): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2013-10-11 15:42:11 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): importance |
High |
Undecided |
|
