| 2014-03-23 21:11:58 |
Antti Kaijanmäki |
bug |
|
|
added bug |
| 2014-05-29 10:32:49 |
Tony Espy |
ofono (Ubuntu): assignee |
|
Tony Espy (awe) |
|
| 2014-05-29 10:32:53 |
Tony Espy |
ofono (Ubuntu): status |
New |
Confirmed |
|
| 2014-05-29 10:32:58 |
Tony Espy |
ofono (Ubuntu): importance |
Undecided |
High |
|
| 2014-05-29 12:28:21 |
Tony Espy |
bug task added |
|
network-manager (Ubuntu) |
|
| 2014-05-29 12:28:40 |
Tony Espy |
bug task added |
|
urfkill (Ubuntu) |
|
| 2014-05-29 12:29:00 |
Tony Espy |
bug task added |
|
indicator-network (Ubuntu) |
|
| 2014-05-29 12:29:24 |
Tony Espy |
bug task added |
|
powerd (Ubuntu) |
|
| 2014-05-29 12:35:00 |
Jamie Strandboge |
indicator-network (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-05-29 12:35:04 |
Jamie Strandboge |
network-manager (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-05-29 12:35:08 |
Jamie Strandboge |
powerd (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-05-29 12:35:11 |
Jamie Strandboge |
urfkill (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-05-29 12:35:22 |
Jamie Strandboge |
ofono (Ubuntu): assignee |
Tony Espy (awe) |
Jamie Strandboge (jdstrand) |
|
| 2014-05-29 12:38:02 |
Jamie Strandboge |
summary |
[security] setting "dangerous" properties such as [service].Modem 'Powered' and 'Online' should be restricted. |
[security] please use apparmor to restrict access to ofono to approved software |
|
| 2014-05-29 12:38:16 |
Jamie Strandboge |
summary |
[security] please use apparmor to restrict access to ofono to approved software |
[security] please use apparmor to restrict access to ofono to approved services |
|
| 2014-05-29 13:11:38 |
Tony Espy |
bug |
|
|
added subscriber Michael Terry |
| 2014-05-29 13:11:53 |
Tony Espy |
bug task added |
|
nuntium (Ubuntu) |
|
| 2014-05-29 13:12:26 |
Tony Espy |
bug |
|
|
added subscriber Alfonso Sanchez-Beato |
| 2014-05-29 13:12:43 |
Tony Espy |
bug |
|
|
added subscriber Mathieu Trudel-Lapierre |
| 2014-05-29 13:12:57 |
Tony Espy |
bug |
|
|
added subscriber Sergio Schvezov |
| 2014-05-29 13:14:34 |
Tony Espy |
bug |
|
|
added subscriber Manuel de la Peña |
| 2014-05-29 14:36:26 |
Tony Espy |
bug task added |
|
ubuntu-system-settings (Ubuntu) |
|
| 2014-06-03 21:45:06 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-06-03 21:45:08 |
Jamie Strandboge |
nuntium (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-06-04 15:25:39 |
Jamie Strandboge |
indicator-network (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:25:44 |
Jamie Strandboge |
network-manager (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:25:50 |
Jamie Strandboge |
nuntium (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:25:54 |
Jamie Strandboge |
ofono (Ubuntu): status |
Confirmed |
In Progress |
|
| 2014-06-04 15:25:59 |
Jamie Strandboge |
powerd (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:26:03 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:26:08 |
Jamie Strandboge |
urfkill (Ubuntu): status |
New |
In Progress |
|
| 2014-06-04 15:26:10 |
Jamie Strandboge |
tags |
|
apparmor application-confinement rtm14 |
|
| 2014-06-10 19:28:11 |
Tony Espy |
bug task added |
|
ubuntu-download-manager (Ubuntu) |
|
| 2014-06-10 19:28:32 |
Tony Espy |
ubuntu-download-manager (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-06-10 19:28:44 |
Tony Espy |
ubuntu-download-manager (Ubuntu): status |
New |
Triaged |
|
| 2014-06-10 20:19:24 |
Ricardo Salveti |
bug |
|
|
added subscriber Ricardo Salveti |
| 2014-06-24 19:32:16 |
Jamie Strandboge |
attachment added |
|
ofono_1.12.bzr6868+14.10.20140513.1-0ubuntu3.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138452/+files/ofono_1.12.bzr6868%2B14.10.20140513.1-0ubuntu3.debdiff |
|
| 2014-06-24 19:32:33 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu): status |
Triaged |
In Progress |
|
| 2014-06-24 19:33:01 |
Jamie Strandboge |
attachment added |
|
network-manager_0.9.8.8-0ubuntu19.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138454/+files/network-manager_0.9.8.8-0ubuntu19.debdiff |
|
| 2014-06-24 19:33:30 |
Jamie Strandboge |
attachment added |
|
nuntium_0.1+14.10.20140529-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138455/+files/nuntium_0.1%2B14.10.20140529-0ubuntu2.debdiff |
|
| 2014-06-24 19:34:23 |
Jamie Strandboge |
attachment added |
|
powerd_0.15+14.10.20140612-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138456/+files/powerd_0.15%2B14.10.20140612-0ubuntu2.debdiff |
|
| 2014-06-24 19:34:56 |
Jamie Strandboge |
attachment added |
|
ubuntu-system-settings_0.3+14.10.20140623-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138457/+files/ubuntu-system-settings_0.3%2B14.10.20140623-0ubuntu2.debdiff |
|
| 2014-06-24 19:35:23 |
Jamie Strandboge |
attachment added |
|
urfkill_0.6.0~20140527.173146.03f4503-0ubuntu1~mtrudel1ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138458/+files/urfkill_0.6.0%7E20140527.173146.03f4503-0ubuntu1%7Emtrudel1ubuntu1.debdiff |
|
| 2014-06-24 20:03:52 |
Jamie Strandboge |
attachment added |
|
ubuntu-download-manager_0.3+14.10.20140523-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138485/+files/ubuntu-download-manager_0.3%2B14.10.20140523-0ubuntu2.debdiff |
|
| 2014-06-24 20:21:12 |
Ubuntu Foundations Team Bug Bot |
tags |
apparmor application-confinement rtm14 |
apparmor application-confinement patch rtm14 |
|
| 2014-06-24 20:28:14 |
Jamie Strandboge |
attachment added |
|
indicator-network_0.5.1+14.10.20140602-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1296415/+attachment/4138507/+files/indicator-network_0.5.1%2B14.10.20140602-0ubuntu2.debdiff |
|
| 2014-06-24 20:39:38 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/ofono/ofono-lp1296415 |
|
| 2014-06-24 20:43:21 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/network-manager/network-manager-lp1296415 |
|
| 2014-06-24 20:46:02 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/indicator-network/indicator-network-lp1296415 |
|
| 2014-06-24 20:49:27 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/nuntium/nuntium-lp1296415 |
|
| 2014-06-24 20:54:01 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/powerd/powerd-lp1296415 |
|
| 2014-06-24 20:58:56 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/ubuntu-download-manager/ubuntu-download-manager-lp1296415 |
|
| 2014-06-24 21:00:58 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/ubuntu-system-settings/ubuntu-system-settings-lp1296415 |
|
| 2014-06-24 21:22:41 |
Jamie Strandboge |
description |
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
|
| 2014-06-24 21:47:05 |
Jamie Strandboge |
description |
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
|
| 2014-06-24 21:58:58 |
Jamie Strandboge |
branch unlinked |
lp:~jdstrand/ofono/ofono-lp1296415 |
|
|
| 2014-06-24 21:59:15 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/ofono/ofono-lp1296415 |
|
| 2014-06-24 22:56:11 |
Jamie Strandboge |
attachment removed |
ofono_1.12.bzr6868+14.10.20140513.1-0ubuntu3.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138452/+files/ofono_1.12.bzr6868%2B14.10.20140513.1-0ubuntu3.debdiff |
|
|
| 2014-06-24 22:56:29 |
Jamie Strandboge |
attachment removed |
network-manager_0.9.8.8-0ubuntu19.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138454/+files/network-manager_0.9.8.8-0ubuntu19.debdiff |
|
|
| 2014-06-24 22:56:46 |
Jamie Strandboge |
attachment removed |
nuntium_0.1+14.10.20140529-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138455/+files/nuntium_0.1%2B14.10.20140529-0ubuntu2.debdiff |
|
|
| 2014-06-24 22:57:02 |
Jamie Strandboge |
attachment removed |
powerd_0.15+14.10.20140612-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138456/+files/powerd_0.15%2B14.10.20140612-0ubuntu2.debdiff |
|
|
| 2014-06-24 22:57:18 |
Jamie Strandboge |
attachment removed |
ubuntu-system-settings_0.3+14.10.20140623-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138457/+files/ubuntu-system-settings_0.3%2B14.10.20140623-0ubuntu2.debdiff |
|
|
| 2014-06-24 22:58:22 |
Jamie Strandboge |
attachment removed |
urfkill_0.6.0~20140527.173146.03f4503-0ubuntu1~mtrudel1ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138458/+files/urfkill_0.6.0%7E20140527.173146.03f4503-0ubuntu1%7Emtrudel1ubuntu1.debdiff |
|
|
| 2014-06-24 22:58:35 |
Jamie Strandboge |
attachment removed |
ubuntu-download-manager_0.3+14.10.20140523-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138485/+files/ubuntu-download-manager_0.3%2B14.10.20140523-0ubuntu2.debdiff |
|
|
| 2014-06-24 22:58:50 |
Jamie Strandboge |
attachment removed |
indicator-network_0.5.1+14.10.20140602-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138507/+files/indicator-network_0.5.1%2B14.10.20140602-0ubuntu2.debdiff |
|
|
| 2014-06-24 23:00:34 |
Jamie Strandboge |
attachment added |
|
urfkill_0.6.0~20140527.173146.03f4503-0ubuntu1~mtrudel1ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1296415/+attachment/4138577/+files/urfkill_0.6.0%7E20140527.173146.03f4503-0ubuntu1%7Emtrudel1ubuntu1.debdiff |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
nominated for series |
|
Ubuntu Utopic |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
network-manager (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
indicator-network (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
ofono (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
urfkill (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
powerd (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
ubuntu-system-settings (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
ubuntu-download-manager (Ubuntu Utopic) |
|
| 2014-06-25 12:07:15 |
Jamie Strandboge |
bug task added |
|
nuntium (Ubuntu Utopic) |
|
| 2014-06-25 12:07:41 |
Jamie Strandboge |
bug task added |
|
isc-dhcp (Ubuntu) |
|
| 2014-06-25 12:08:17 |
Jamie Strandboge |
isc-dhcp (Ubuntu Utopic): status |
New |
In Progress |
|
| 2014-06-25 12:08:17 |
Jamie Strandboge |
isc-dhcp (Ubuntu Utopic): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-06-25 15:02:15 |
Jamie Strandboge |
isc-dhcp (Ubuntu Utopic): status |
In Progress |
Fix Committed |
|
| 2014-06-26 17:08:41 |
Launchpad Janitor |
isc-dhcp (Ubuntu Utopic): status |
Fix Committed |
Fix Released |
|
| 2014-06-26 18:55:14 |
Jamie Strandboge |
description |
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
NOTE: After further review from the security team, unfortunately what is presented as a solution in this bug is not sufficient to block unconfined processes from connecting to ofono for essentially two reasons:
a) anything that is unconfined can change into another profile, so an unconfined process can simply change into the profile of one of the allowed services, and
b) this doesn't protect against scenarios where the user is able to alter the behavior of the allowed services running in the user session (eg, indicator-network and ubuntu-system-settings)
'a' is solvable by making sure that the user's session starts under a new AppArmor "user-session" profile that prevents changing profile in to one of the allowed services (of course, the user session services continue to run under their own profiles). We'd have to investigate the best method for profile attachment in this case as well.
'b' is perhaps solvable by more strictly confining these allowed user session services (eg, 'audit deny ptrace tracedby peer=user-session, audit deny owner /** m, preventing QML loading, future AppArmor environment filtering, etc') along with, importantly, hardening these services to the point that they can't be controlled via environment, configuration, library loading, etc, etc. An alternative solution would be to run these services as another user in such a way that the user cannot alter their behavior beyond what is exposed in the UI.
Preventing unconfined from doing things is a difficult prospect and while I think with the recent improvements with AppArmor over the last two cycles finally makes the notion plausible, significant work remains to solve 'a' and 'b'.
Description:
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
|
| 2014-06-26 18:58:06 |
Jamie Strandboge |
description |
NOTE: After further review from the security team, unfortunately what is presented as a solution in this bug is not sufficient to block unconfined processes from connecting to ofono for essentially two reasons:
a) anything that is unconfined can change into another profile, so an unconfined process can simply change into the profile of one of the allowed services, and
b) this doesn't protect against scenarios where the user is able to alter the behavior of the allowed services running in the user session (eg, indicator-network and ubuntu-system-settings)
'a' is solvable by making sure that the user's session starts under a new AppArmor "user-session" profile that prevents changing profile in to one of the allowed services (of course, the user session services continue to run under their own profiles). We'd have to investigate the best method for profile attachment in this case as well.
'b' is perhaps solvable by more strictly confining these allowed user session services (eg, 'audit deny ptrace tracedby peer=user-session, audit deny owner /** m, preventing QML loading, future AppArmor environment filtering, etc') along with, importantly, hardening these services to the point that they can't be controlled via environment, configuration, library loading, etc, etc. An alternative solution would be to run these services as another user in such a way that the user cannot alter their behavior beyond what is exposed in the UI.
Preventing unconfined from doing things is a difficult prospect and while I think with the recent improvements with AppArmor over the last two cycles finally makes the notion plausible, significant work remains to solve 'a' and 'b'.
Description:
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
NOTE: After further review from the security team, unfortunately what is presented as a solution in this bug is not sufficient to block unconfined processes from connecting to ofono for essentially two reasons:
a) anything that is unconfined can change into another profile, so an unconfined process can simply change into the profile of one of the allowed services, and
b) this doesn't protect against scenarios where the user is able to alter the behavior of the allowed services running in the user session (eg, indicator-network and ubuntu-system-settings)
'a' is solvable by making sure that the user's session starts under a new AppArmor "user-session" profile that prevents changing profile in to one of the allowed services (of course, the user session services continue to run under their own profiles). We'd have to investigate the best method for profile attachment in this case as well.
'b' is perhaps solvable by more strictly confining these allowed user session services (eg, 'audit deny ptrace tracedby peer=user-session, audit deny owner /** m, preventing QML loading, future AppArmor environment filtering, etc') along with, importantly, hardening these services to the point that they can't be controlled via environment, configuration, library loading, etc, etc. An alternative solution would be to run these services as another user in such a way that the user cannot alter their behavior beyond what is exposed in the UI.
Preventing unconfined from doing things is a difficult prospect and while I think with the recent improvements with AppArmor over the last two cycles finally makes the notion plausible, significant work remains to solve 'a' and 'b'. This is cannot be achieved for RTM (note, this only affected limiting unconfined and has no effect on application isolation, which is in full effect and does not suffer from this at all).
Description:
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
|
| 2014-06-27 16:54:23 |
Jamie Strandboge |
description |
NOTE: After further review from the security team, unfortunately what is presented as a solution in this bug is not sufficient to block unconfined processes from connecting to ofono for essentially two reasons:
a) anything that is unconfined can change into another profile, so an unconfined process can simply change into the profile of one of the allowed services, and
b) this doesn't protect against scenarios where the user is able to alter the behavior of the allowed services running in the user session (eg, indicator-network and ubuntu-system-settings)
'a' is solvable by making sure that the user's session starts under a new AppArmor "user-session" profile that prevents changing profile in to one of the allowed services (of course, the user session services continue to run under their own profiles). We'd have to investigate the best method for profile attachment in this case as well.
'b' is perhaps solvable by more strictly confining these allowed user session services (eg, 'audit deny ptrace tracedby peer=user-session, audit deny owner /** m, preventing QML loading, future AppArmor environment filtering, etc') along with, importantly, hardening these services to the point that they can't be controlled via environment, configuration, library loading, etc, etc. An alternative solution would be to run these services as another user in such a way that the user cannot alter their behavior beyond what is exposed in the UI.
Preventing unconfined from doing things is a difficult prospect and while I think with the recent improvements with AppArmor over the last two cycles finally makes the notion plausible, significant work remains to solve 'a' and 'b'. This is cannot be achieved for RTM (note, this only affected limiting unconfined and has no effect on application isolation, which is in full effect and does not suffer from this at all).
Description:
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
NOTE: After further review from the security team, unfortunately what is presented as a solution in this bug is not sufficient to block unconfined processes from connecting to ofono for essentially two reasons:
a) anything that is unconfined can change into another profile, so an unconfined process can simply change into the profile of one of the allowed services, and
b) this doesn't protect against scenarios where the user is able to alter the behavior of the allowed services running in the user session (eg, indicator-network and ubuntu-system-settings)
'a' is solvable by making sure that the user's session starts under a new AppArmor "user-session" profile that prevents changing profile in to one of the allowed services (of course, the user session services continue to run under their own profiles). We'd have to investigate the best method for profile attachment in this case as well. An alternative might be to store the profile attachment in the inode of the binary when AppArmor adds this.
'b' is perhaps solvable by more strictly confining these allowed user session services (eg, 'audit deny ptrace tracedby peer=user-session, audit deny owner /** m, preventing QML loading, future AppArmor environment filtering, etc') along with, importantly, hardening these services to the point that they can't be controlled via environment, configuration, library loading, etc, etc. An alternative solution would be to run these services as another user in such a way that the user cannot alter their behavior beyond what is exposed in the UI.
Preventing unconfined from doing things is a difficult prospect and while I think with the recent improvements with AppArmor over the last two cycles finally makes the notion plausible, significant work remains to solve 'a' and 'b'. This is cannot be achieved for RTM (note, this only affected limiting unconfined and has no effect on application isolation, which is in full effect and does not suffer from this at all).
Description:
It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
- indicator-network
- network-manager (and dispatcher.d/03mmsproxy)
- nuntium
- telepathy-ofono
- ofono-scripts
- powerd
- ubuntu-download-manager
- system-settings
- urfkill
Each of the above needs to have a profile created for it, adjusting the boot scripts as necessary to ensure that the profile is loaded before the service starts. The peer profile implementation will be wide open as the purpose of the profile is (currently) to simply ensure the process of the service has the correct AppArmor labeling (though this opens the possibility to confine these services down the road if desired).
Merge requests have been requested for everything except urfkill, which has a debdiff attached to this bug. As mentioned, the AppArmor profiles for everything except ofonod is wide open so the risk of regression is very low for these. In fact, if it is helpful, everything except ofono could be uploaded to the archive independently and at any time.
For ofono, as mentioned, the AppArmor profile is also lenient except for the policy for its DBus interface. It is critical that ofono is updated at the same time or after all the other packages in this bug, otherwise any packages that aren't updated will fail to connect to ofono.
I've been running this configuration on my phone for weeks with no denials (excepting 03mmsproxy which I adjusted for yesterday). I've tested the packaging on x86 emulator to make sure that the profiles are installed and loaded properly on boot.
Test Plan (additional to any existing appropriate test plans)
1. Install all services on a device
2. reboot (important to restart the session and any services that aren't
restarted automatically, like nuntium. reboot is easiest). Note the time
of the reboot on the device
3. in addition to any applicable test plans, after full boot:
adb shell grep DEN /var/log/syslog # there should be no denials for
# ofono after the system boots (there
# likely will be denials during
# upgrade)
adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
4. make a call
5. send a text
6. send an mms (if possible)
7. connect to wifi
8. connect to 3G
9. download an app
10. toggle wifi in system-settings
11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and
/usr/share/ofono/scripts/online-modem
12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
during the testing
= Original text =
We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident. |
|
| 2014-07-10 18:26:20 |
Tony Espy |
tags |
apparmor application-confinement patch rtm14 |
apparmor application-confinement patch |
|
| 2014-07-16 19:23:31 |
Tony Espy |
ofono (Ubuntu Utopic): importance |
High |
Wishlist |
|
| 2014-07-17 16:23:58 |
Jamie Strandboge |
indicator-network (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:24:17 |
Jamie Strandboge |
network-manager (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:24:35 |
Jamie Strandboge |
nuntium (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:26:25 |
Jamie Strandboge |
ofono (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:26:30 |
Jamie Strandboge |
powerd (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:26:36 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:33:43 |
Jamie Strandboge |
urfkill (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:33:49 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2014-07-17 16:34:09 |
Jamie Strandboge |
indicator-network (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:34:11 |
Jamie Strandboge |
indicator-network (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:14 |
Jamie Strandboge |
indicator-network (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:34:17 |
Jamie Strandboge |
indicator-network (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:23 |
Jamie Strandboge |
network-manager (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:34:25 |
Jamie Strandboge |
network-manager (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:28 |
Jamie Strandboge |
network-manager (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:34:32 |
Jamie Strandboge |
network-manager (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:37 |
Jamie Strandboge |
nuntium (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:34:39 |
Jamie Strandboge |
nuntium (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:42 |
Jamie Strandboge |
nuntium (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:34:45 |
Jamie Strandboge |
nuntium (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:34:49 |
Jamie Strandboge |
ofono (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:34:52 |
Jamie Strandboge |
ofono (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:34:57 |
Jamie Strandboge |
powerd (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:34:59 |
Jamie Strandboge |
powerd (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:02 |
Jamie Strandboge |
powerd (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:35:06 |
Jamie Strandboge |
powerd (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:12 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:35:15 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:18 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:35:21 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:27 |
Jamie Strandboge |
urfkill (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:35:30 |
Jamie Strandboge |
urfkill (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:33 |
Jamie Strandboge |
urfkill (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:35:37 |
Jamie Strandboge |
urfkill (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:42 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu): status |
In Progress |
Triaged |
|
| 2014-07-17 16:35:45 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:35:48 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu Utopic): status |
Won't Fix |
Triaged |
|
| 2014-07-17 16:35:50 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu Utopic): importance |
Undecided |
Wishlist |
|
| 2014-07-17 16:36:32 |
Jamie Strandboge |
indicator-network (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:36:37 |
Jamie Strandboge |
network-manager (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:36:43 |
Jamie Strandboge |
nuntium (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:36:49 |
Jamie Strandboge |
ofono (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:36:54 |
Jamie Strandboge |
powerd (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:36:59 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:37:04 |
Jamie Strandboge |
urfkill (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:37:09 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu Utopic): status |
Triaged |
Won't Fix |
|
| 2014-07-17 16:38:15 |
Jamie Strandboge |
indicator-network (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:38:28 |
Jamie Strandboge |
indicator-network (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:38:55 |
Jamie Strandboge |
network-manager (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:39:13 |
Jamie Strandboge |
network-manager (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:39:27 |
Jamie Strandboge |
nuntium (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:40:24 |
Jamie Strandboge |
nuntium (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:41:22 |
Jamie Strandboge |
ofono (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:43:56 |
Jamie Strandboge |
ofono (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:44:12 |
Jamie Strandboge |
powerd (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:44:26 |
Jamie Strandboge |
powerd (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:45:00 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:45:53 |
Jamie Strandboge |
ubuntu-download-manager (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:46:36 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:46:53 |
Jamie Strandboge |
ubuntu-system-settings (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:47:10 |
Jamie Strandboge |
urfkill (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
|
|
| 2014-07-17 16:47:26 |
Jamie Strandboge |
urfkill (Ubuntu Utopic): assignee |
Jamie Strandboge (jdstrand) |
|
|
