AppArmor policy for scope zmq access is too lenient
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unity-scopes-api (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Currently in apparmor-
owner /run/user/
owner /run/user/
owner /run/user/
Note that all scopes, regardless of whether they use the ubuntu-
1. How will the scope-registry handle when either /run/user/
2. In addition to dealing with /run/user/
For '1', standard defensive programming should be sufficient and someone should verify that the scopes API is handling when these files already exist (as sockets, regular files, etc, etc).
For '2', standard defensive programming should also be used, but that isn't enough. I suggested at the sprint that these endpoints should be made application specific by their name like with the other endpoints, but was told this is problematic. I can (and will) update the apparmor policy to use this rule:
owner /run/user/
but this doesn't solve the problem since a malicious app writer will just pick something matching that apparmor regular expression (AARE). AIUI, it is difficult/
Thanks!
Changed in unity-api (Ubuntu): | |
importance: | Undecided → High |
tags: | added: application-confinement rtm14 |
summary: |
- scope zmq access is too lenient + AppArmor policy for scope zmq access is too lenient |
information type: | Public → Public Security |
description: | updated |
description: | updated |
description: | updated |
no longer affects: | unity-api (Ubuntu) |
Changed in unity-scopes-api: | |
importance: | High → Wishlist |
affects: | unity-scopes-api → unity-scopes-api (Ubuntu) |
Changed in unity-scopes-api (Ubuntu): | |
status: | New → Confirmed |
Changed in unity-scopes-api (Ubuntu): | |
assignee: | Michi Henning (michihenning) → nobody |
Taking the liberty of changing the project