| 2014-06-03 19:21:41 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2014-06-03 19:21:53 |
Jamie Strandboge |
unity-api (Ubuntu): importance |
Undecided |
High |
|
| 2014-06-03 19:22:46 |
Jamie Strandboge |
tags |
|
application-confinement rtm14 |
|
| 2014-06-03 19:23:17 |
Jamie Strandboge |
summary |
scope zmq access is too lenient |
AppArmor policy for scope zmq access is too lenient |
|
| 2014-06-03 19:23:27 |
Jamie Strandboge |
information type |
Public |
Public Security |
|
| 2014-06-03 19:27:27 |
Jamie Strandboge |
description |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there a still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists? Defensive programming should be able to handle this case
2. the /run/user/[0-9]*/zmq/c-*-r should also use standard defensive programming, but there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server.
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 cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there are still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists?
2. the /run/user/[0-9]*/zmq/c-*-r should also use standard defensive programming, but there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server.
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 cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
|
| 2014-06-03 19:30:10 |
Jamie Strandboge |
description |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there are still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists?
2. the /run/user/[0-9]*/zmq/c-*-r should also use standard defensive programming, but there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server.
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 cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there are still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists?
2. In addition to dealing with /run/user/[0-9]*/zmq/c-*-r possibly already existing, there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server when the user upgrades (the fact that it is in /run doesn't really help-- the malicious scope can save the file in its scope-specific directory then copy it in to place to make sure it is always there).
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 cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
|
| 2014-06-03 19:33:08 |
Jamie Strandboge |
description |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there are still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists?
2. In addition to dealing with /run/user/[0-9]*/zmq/c-*-r possibly already existing, there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server when the user upgrades (the fact that it is in /run doesn't really help-- the malicious scope can save the file in its scope-specific directory then copy it in to place to make sure it is always there).
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 cannot be made application specific by there name. I can (and will) update the apparmor policy to use this rule:
owner /run/user/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq-local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
Currently in apparmor-easyprof-ubuntu 1.2.3 we have:
owner /run/user/[0-9]*/zmq/Registry-s rw,
owner /run/user/[0-9]*/zmq/Registry-p r,
owner /run/user/[0-9]*/zmq/c-*-r rw,
Note that all scopes, regardless of whether they use the ubuntu-scope-network or ubuntu-scope-local-content templates have access to these overlapped accesses. While we discussed the apparmor policy at length at the recent sprint, in thinking about this more there are still a few issues:
1. How will the scope-registry handle when either /run/user/[0-9]*/zmq/Registry-s or /run/user/[0-9]*/zmq/Registry-p already exists?
2. In addition to dealing with /run/user/[0-9]*/zmq/c-*-r possibly already existing, there is an additional issue with this access-- because the ubuntu-scope-network and ubuntu-scope-local-content templates both allow this access, this allows a malicious scope author to create a scope using the ubuntu-scope-local-content template, then collect files off the filesystem and store them in /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c, then upload a new version of the scope using the ubuntu-scope-network template, which can then ship /run/user/[0-9]*/zmq/c-I_can_leak_your_files.tar.gz-c off to a remote server when the user upgrades (the fact that it is in /run doesn't really help-- the malicious scope can save the file in its scope-specific directory then copy it in to place to make sure it is always there).
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/[0-9]*/zmq/c-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]-r rw,
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/impossible to make these endpoints application specific (eg, "/run/user/[0-9]*/zmq/c-@{APP_PKGNAME}-r" which would be the preferred fix). If that is the case, we can either namespace this endpoint in zmq/local-fs/c-*r and zmq/local-net/c-*r and adjust the policy templates accordingly. I have a feeling this will have the same problems (or worse) as making the endpoint application specific since you'd need to track the type of scope this is. Alternatively, you could have a garbage collector to unconditionally remove any non-unix domain socket files and unused unix domain socket files that match zmq/c-*-r. While making these endpoints application specific would be cleanest from a policy point of view, implementing good garbage collection (perhaps triggered on scope start/register) would be sufficient to close this bug.
Thanks! |
|
| 2014-06-03 20:11:52 |
Pete Woods |
bug task added |
|
unity-scopes-api |
|
| 2014-06-03 20:12:02 |
Pete Woods |
unity-scopes-api: importance |
Undecided |
High |
|
| 2014-06-03 20:12:44 |
Pete Woods |
unity-api (Ubuntu): status |
New |
Invalid |
|
| 2014-06-03 20:54:08 |
Jamie Strandboge |
bug task deleted |
unity-api (Ubuntu) |
|
|
| 2014-06-04 09:36:35 |
Michał Karnicki |
bug |
|
|
added subscriber Michał Karnicki |
| 2014-07-03 01:38:46 |
Michi Henning |
unity-scopes-api: assignee |
|
Michi Henning (michihenning) |
|
| 2014-07-31 14:40:57 |
Jamie Strandboge |
tags |
application-confinement rtm14 |
application-confinement |
|
| 2014-08-05 07:29:25 |
Michi Henning |
unity-scopes-api: importance |
High |
Wishlist |
|
| 2014-09-10 02:09:50 |
Michi Henning |
affects |
unity-scopes-api |
unity-scopes-api (Ubuntu) |
|
| 2014-09-15 12:37:44 |
Jamie Strandboge |
unity-scopes-api (Ubuntu): status |
New |
Confirmed |
|
| 2016-02-25 16:19:38 |
Michał Karnicki |
removed subscriber Michał Karnicki |
|
|
|
| 2017-05-13 01:22:08 |
Michi Henning |
unity-scopes-api (Ubuntu): assignee |
Michi Henning (michihenning) |
|
|
