| 2013-07-02 20:34:51 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2013-07-02 20:35:14 |
Jamie Strandboge |
bug task added |
|
touch-preview-images |
|
| 2013-07-02 20:35:28 |
Jamie Strandboge |
tags |
|
application-confinement |
|
| 2013-08-08 17:34:33 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well. |
|
| 2013-08-08 17:34:46 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): status |
New |
Triaged |
|
| 2013-08-08 17:34:58 |
Jamie Strandboge |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-08-08 17:34:58 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu Saucy) |
|
| 2013-09-04 03:01:49 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu) |
|
| 2013-09-04 03:05:35 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
|
| 2013-09-04 03:05:42 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): importance |
Undecided |
High |
|
| 2013-09-04 03:05:48 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): status |
New |
Confirmed |
|
| 2013-09-04 03:06:06 |
Jamie Strandboge |
bug |
|
|
added subscriber Thomas Voß |
| 2013-09-04 03:06:12 |
Jamie Strandboge |
bug |
|
|
added subscriber Loïc Minier |
| 2013-09-04 03:06:23 |
Jamie Strandboge |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2013-09-04 03:09:24 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
|
| 2013-09-04 16:07:08 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): assignee |
|
Ubuntu Phonedations bugs (ubuntu-phonedations-bugs) |
|
| 2013-09-05 02:52:42 |
Ricardo Salveti |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-08-08:
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- audio flinger
- media service
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-09-04 (audioflinger and media service are not used anymore):
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
|
| 2013-10-11 15:55:47 |
Jamie Strandboge |
nominated for series |
|
Ubuntu T-series |
|
| 2013-10-11 15:55:47 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu T-series) |
|
| 2013-10-11 15:55:47 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu T-series) |
|
| 2013-10-11 15:55:55 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Saucy): status |
Triaged |
Won't Fix |
|
| 2013-10-11 15:56:00 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu T-series): status |
New |
Confirmed |
|
| 2013-10-11 17:41:56 |
Jamie Strandboge |
summary |
SDK applications require access to /dev/binder |
All SDK applications require access to /dev/binder, even when using mir |
|
| 2013-10-16 21:02:10 |
Jamie Strandboge |
summary |
All SDK applications require access to /dev/binder, even when using mir |
All SDK applications require access to /dev/binder |
|
| 2013-10-16 21:03:28 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-09-04 (audioflinger and media service are not used anymore):
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for application confinement to work. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-09-04 (audioflinger and media service are not used anymore):
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for fine-grained application confinement to work.
Update 2013-10-16:
This is still an issue on image 99. ricmm mentioned that all applications use the sensors so all applications have access to binder-- so this is why even mir applications need it. |
|
| 2013-10-16 21:25:58 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy.
Update 2013-09-04 (audioflinger and media service are not used anymore):
All apps currently need this access because of surface flinger. The following are the binder services that Ubuntu currently uses:
- surface flinger
- camera
- sensors
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the 5 remaining binder services listed above, surface flinger, audio flinger and the media service are being moved to HAL (ie, don't use binder but use the device directly via the generalized HAL API). Camera should move to HAL in 14.04, and sensors may in 14.04 or later.
Therefore, when surface flinger is no longer used, we can remove /dev/binder from the ubuntu-sdk apparmor template, and move it into the various policy groups. As we move to HAL in the various services, we'll update those policy groups to remove /dev/binder as well.
Update 2013-09-03:
Unfortunately when I tested Mir on mako recently, applications failed to start if I took away access to /dev/binder. Eg:
Aug 23 21:18:13 ubuntu-phablet kernel: [ 9531.171096] type=1400
audit(1377292693.295:596): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.jdstrand.evilapp_evilapp_0.5" name="/dev/binder"
pid=6035 comm="qmlscene" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
Aug 23 21:24:16 ubuntu-phablet kernel: [ 9894.826978] type=1400
audit(1377293056.953:1109): apparmor="DENIED" operation="open" parent=769
profile="com.ubuntu.developer.mhall119.xda-developers-app_xda-developers_0.1.5"
name="/dev/binder" pid=6415 comm="qmlscene" requested_mask="rw" denied_mask="rw"
fsuid=32011 ouid=0
Why would an app on Mir need access to /dev/binder? Does
libhybris need to be updated in some way?
I verified that surface_flinger is not running:
$ ps auxww | grep [s]urf
$
Getting rid of /dev/binder access (ie, executing our plan as of 2013-08-08) is critical for fine-grained application confinement to work.
Update 2013-10-16:
This is still an issue on image 99. ricmm mentioned that all applications use the sensors so all applications have access to binder-- so this is why even mir applications need it. |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy because there is no mediation between binder services.
All apps currently need this access because of the sensors service (even on mir). The following are the binder services that Ubuntu currently uses:
- camera
- sensors
- surface flinger (only used as fallback now)
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the remaining binder services listed above, camera is moving to HAL in 14.04 and sensors shoudl also move there as well in 14.04.
This bug will be resolved when /dev/binder is no longer used or it is only used by one service and therefore the /dev/binder access can move into the appropriate policy group.
Right now, because all apps needs access to /dev/binder, all apps end up with access to the camera and sensors services even when these policy groups are not specified. Getting rid of /dev/binder access is for fine-grained application confinement to work correctly. |
|
| 2013-10-17 17:12:34 |
Launchpad Janitor |
lxc-android-config (Ubuntu T-series): status |
New |
Confirmed |
|
| 2013-12-12 18:07:32 |
Jamie Strandboge |
lxc-android-config (Ubuntu Saucy): status |
Confirmed |
Won't Fix |
|
| 2013-12-12 18:07:47 |
Jamie Strandboge |
lxc-android-config (Ubuntu Trusty): assignee |
|
Ubuntu Phonedations bugs (ubuntu-phonedations-bugs) |
|
| 2013-12-12 18:07:52 |
Jamie Strandboge |
lxc-android-config (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2014-04-04 13:51:34 |
Daniel Holbach |
bug |
|
|
added subscriber Daniel Holbach |
| 2014-06-26 20:21:11 |
Jamie Strandboge |
description |
SDK applications need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy because there is no mediation between binder services.
All apps currently need this access because of the sensors service (even on mir). The following are the binder services that Ubuntu currently uses:
- camera
- sensors
- surface flinger (only used as fallback now)
location was in this group but is already moved away. vibrate is not implemented but when it is it will only use our API (ie, not binder). Of the remaining binder services listed above, camera is moving to HAL in 14.04 and sensors shoudl also move there as well in 14.04.
This bug will be resolved when /dev/binder is no longer used or it is only used by one service and therefore the /dev/binder access can move into the appropriate policy group.
Right now, because all apps needs access to /dev/binder, all apps end up with access to the camera and sensors services even when these policy groups are not specified. Getting rid of /dev/binder access is for fine-grained application confinement to work correctly. |
SDK applications sometimes need the following AppArmor policy to run:
/dev/binder rw,
The writes to /dev/binder allow applications to attack binder directly which weakens our application confinement policy because there is no mediation between binder services.
The following are the binder services that Ubuntu currently uses:
- camera
- media playback service (used by media-hub)
location was in this group but is already moved away. surface flinger was used as a fallback but has been removed. vibrate is not implemented but when it is it will only use our API (ie, not binder). sensors was implemented as usensors in 14.10. Of the remaining binder services listed above, camera is still present for video recording and media playback service implements a subset of the android API for media playback (it is used by media-hub).
This bug will be resolved when /dev/binder is no longer used or it is only used by one service and therefore the /dev/binder access can move into the appropriate policy group.
Right now, because all apps needs access to /dev/binder, all apps end up with access to the camera and media playback services even when these policy groups are not specified. Getting rid of /dev/binder access is for fine-grained application confinement to work correctly. |
|
| 2014-06-26 20:21:25 |
Jamie Strandboge |
lxc-android-config (Ubuntu Trusty): status |
Confirmed |
Won't Fix |
|
| 2014-06-26 20:21:27 |
Jamie Strandboge |
nominated for series |
|
Ubuntu Utopic |
|
| 2014-06-26 20:21:27 |
Jamie Strandboge |
bug task added |
|
lxc-android-config (Ubuntu Utopic) |
|
| 2014-06-26 20:21:27 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu Utopic) |
|
| 2014-06-26 20:21:41 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Trusty): status |
Confirmed |
Won't Fix |
|
| 2014-06-26 20:21:45 |
Jamie Strandboge |
bug task deleted |
touch-preview-images |
|
|
| 2014-10-24 02:52:14 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-10-24 02:52:20 |
Jamie Strandboge |
lxc-android-config (Ubuntu Utopic): status |
Confirmed |
Won't Fix |
|
| 2014-10-24 02:52:30 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): importance |
Undecided |
High |
|
| 2014-10-24 02:52:42 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): status |
Triaged |
Confirmed |
|
| 2016-05-30 17:55:00 |
sha |
apparmor-easyprof-ubuntu (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2016-05-30 17:56:36 |
sha |
lxc-android-config (Ubuntu): status |
Confirmed |
New |
|
| 2016-05-31 17:00:26 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): status |
Fix Released |
Confirmed |
|
| 2016-05-31 17:00:30 |
Jamie Strandboge |
lxc-android-config (Ubuntu): status |
New |
Confirmed |
|
