https://wiki.mozilla.org/api.php?action=feedcontributions&user=Dchan&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T12:46:56ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Security/B2G/2013_9_21&diff=734909Security/B2G/2013 9 212013-10-22T19:38:51Z<p>Dchan: /* News */</p>
<hr />
<div>== FirefoxOS Security Team Meeting ==<br />
1pm PST, B2G Vidyo room<br />
Prior notes are here:<br />
https://wiki.mozilla.org/Security/B2G/2013_9_14<br />
=== News ===<br />
1.2 Reviews<br />
* https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHNaNUFrQS00Q09FbUFZUmQ5eThpOFE#gid=0<br />
<br />
Gaia Re-Review<br />
* https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AvtHAy6BmzDTdEVMMmZsMENrY3pKNC1Va3ZMM01haGc#gid=0<br />
<br />
Roadmap<br />
* https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHRPbFd0dXZWaTJYby1Ta3hrRzQ5Nmc#gid=0<br />
<br />
<br />
HANDOVER ALL THE THINGS!!!<br />
* Reviews<br />
** Gecko - dchan<br />
** Gaia - mgoodwin<br />
<br />
<br />
* supervisor kinda works (!) (as system)<br />
* jld being very helpful doing seccomp/sandbox tests & stuff<br />
* [:cr] Possible student support in a Bsc thesis context from Marta's student around a malware analysis topic.<br />
* [pt] Leo hardening https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHo4MHpFbm16T2lpZkNwWGkzSV8xX3c#gid=0<br />
<br />
=== Weekly goals===<br />
=== Goal Status Updates ===</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/B2G/2013_9_21&diff=734908Security/B2G/2013 9 212013-10-22T19:38:29Z<p>Dchan: /* News */</p>
<hr />
<div>== FirefoxOS Security Team Meeting ==<br />
1pm PST, B2G Vidyo room<br />
Prior notes are here:<br />
https://wiki.mozilla.org/Security/B2G/2013_9_14<br />
=== News ===<br />
1.2 Reviews<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHNaNUFrQS00Q09FbUFZUmQ5eThpOFE#gid=0<br />
<br />
Gaia Re-Review<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AvtHAy6BmzDTdEVMMmZsMENrY3pKNC1Va3ZMM01haGc#gid=0<br />
<br />
Roadmap<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHRPbFd0dXZWaTJYby1Ta3hrRzQ5Nmc#gid=0<br />
<br />
<br />
HANDOVER ALL THE THINGS!!!<br />
* Reviews<br />
** Gecko - dchan<br />
** Gaia - mgoodwin<br />
<br />
* supervisor kinda works (!) (as system)<br />
* jld being very helpful doing seccomp/sandbox tests & stuff<br />
* [:cr] Possible student support in a Bsc thesis context from Marta's student around a malware analysis topic.<br />
* [pt] Leo hardening https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHo4MHpFbm16T2lpZkNwWGkzSV8xX3c#gid=0<br />
<br />
=== Weekly goals===<br />
=== Goal Status Updates ===</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/B2G/2013_9_21&diff=734905Security/B2G/2013 9 212013-10-22T19:35:24Z<p>Dchan: Created page with "== FirefoxOS Security Team Meeting == 1pm PST, B2G Vidyo room Prior notes are here: https://wiki.mozilla.org/Security/B2G/2013_9_14 === News === 1.2 Reviews https://docs.googl..."</p>
<hr />
<div>== FirefoxOS Security Team Meeting ==<br />
1pm PST, B2G Vidyo room<br />
Prior notes are here:<br />
https://wiki.mozilla.org/Security/B2G/2013_9_14<br />
=== News ===<br />
1.2 Reviews<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHNaNUFrQS00Q09FbUFZUmQ5eThpOFE#gid=0<br />
Gaia Re-Review<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AvtHAy6BmzDTdEVMMmZsMENrY3pKNC1Va3ZMM01haGc#gid=0<br />
Roadmap<br />
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHRPbFd0dXZWaTJYby1Ta3hrRzQ5Nmc#gid=0<br />
HANDOVER ALL THE THINGS!!!<br />
- Reviews<br />
Gecko - dchan<br />
Gaia - mgoodwin<br />
- supervisor kinda works (!) (as system)<br />
- jld being very helpful doing seccomp/sandbox tests & stuff<br />
* [:cr] Possible student support in a Bsc thesis context from Marta's student around a malware analysis topic.<br />
* [pt] Leo hardening https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ap-jgPe0UrMhdHo4MHpFbm16T2lpZkNwWGkzSV8xX3c#gid=0<br />
=== Weekly goals===<br />
=== Goal Status Updates ===</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/B2G/Bluetooth&diff=725721Security/B2G/Bluetooth2013-10-09T21:11:24Z<p>Dchan: Created page with "{{SecReviewInfo |SecReview name=Bluetooth |SecReview target={{bug|727618}} }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }} l
== Introduce Featu..."</p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=Bluetooth<br />
|SecReview target={{bug|727618}}<br />
}}<br />
{{SecReview}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
}}<br />
l<br />
== Introduce Feature==<br />
Bluetooth API Security Review<br />
*Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=727618<br />
*SecReview Bug https://bugzilla.mozilla.org/show_bug.cgi?id=749362<br />
*Wiki: https://wiki.mozilla.org/WebAPI/WebBluetooth<br />
Invitees: Kyle M<br />
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)===<br />
The aim of WebBluetooth is to establish a DOM API to set up and communicate with Bluetooth devices. This includes setting properties on adapters and devices, scanning for devices, bonding, and socket initialization for audio and communication. <br />
For basecamp, we will support:<br />
* HSP (Headset profile, transfers call audio)<br />
* HFP (Hands free profile, encompasses HSP along with the ability to use buttons on a headset to start/end calls, adjust volume, etc...)<br />
* FTP (File transfer PROFILE (not protocol), used as a "share" interface for music/gallery apps to transfer files between other devices)<br />
=== What solutions/approaches were considered other than the proposed solution?===<br />
* using low level bluez sockets<br />
* using low level dbus - Solution we went with<br />
* using dbus with api<br />
=== Why was this solution chosen? ===<br />
Android also uses low level dbus calls, and we couldn't find a decent dbus API that wasn't glib based or didn't do silly things with c++.<br />
=== Any security threats already considered in the design and why? ===<br />
* Access limiting to certain apps so that users cannot create arbitrary ports<br />
== Threat Brainstorming ==<br />
===Attacks from the web===<br />
* Malicious app abusing bluetooth (attacking other devices, DoS the API, consume power?)<br />
** Only certified apps will have access to the bluetooth api<br />
* Certified app being interefered with or coerced into providing data<br />
** App process seperation<br />
** Security review of certified apps which use this API<br />
===Attacks from Bluetooth===<br />
* BlueSnarfing - attack which used a vulnerability to collect data from a device without pairing. L2CAP -> RFCOMM -> Channel 3 (OBEX Push Profile) -> OBEX -> IrMC -> Contacts<br />
* BluePrinting - determine Bluetooth device properties via SDP to uniquely identify a device. (pre pairing)<br />
* BlueSmack - attack which sends large payloads with L2CAP Echo requests<br />
* BlueStab - control characters in UTF-8 encoded BT device name<br />
* BlueBump - forced key exchange<br />
* BlueChop - disrupts established Bluetooth piconets<br />
* BlueSpoof - clone a trusted device (device address, service records, emulate protocols and profiles), disable encryption, force re-pairing.<br />
* BlueDump - cracking the PIN http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/index.html<br />
===Other Questions===<br />
* Which protocols are going to be supported and need fuzz testing? (http://en.wikipedia.org/wiki/Bluetooth_protocols) Please provide exact specification and version number.<br />
* what apps will have bluetooth access? is there going to be a bluetooth app? or is this the settings app and maybe system app that has access? <br />
** Settings for start/stop and pairing, Music/gallery for file sharing (via a "share button" interface)<br />
* What levels of access are there? (all or nothing only, or per device type etc)<br />
** All or nothing<br />
== Conclusions / Action Items == <br />
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug) <br />
dchan - gonk update strategy for bluetooth, camera, etc<br />
dchan - looking into dbus testing tools that ChromeOS uses</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/Gaia/Calendar&diff=718256Security/Reviews/Gaia/Calendar2013-09-30T19:34:03Z<p>Dchan: /* App Review Details */</p>
<hr />
<div>=== App Review Details ===<br />
<br />
* App: Calendar<br />
* Original Review Date: 09 Jan 2013<br />
* Follow-up Review Date: 25 Feb 2013<br />
* Latest Commit: https://github.com/mozilla-b2g/gaia/commit/96dffe8cdb68205e8475a8bd10f455c5a7ccfaff#diff-c41002e94c03079a97d1e5ff3306f3db<br />
* Branch Reviewed: v1-train<br />
* Review Lead: David Chan<br />
* Review Bug: {{bug|754736}} [Security Review] B2G Gaia - Calendar<br />
* Dependency Tree: https://bugzilla.mozilla.org/showdependencytree.cgi?id=754736&hide_resolved=0<br />
<br />
{{Note|Commit data is estimate since it wasn't included in original writeup}}<br />
<br />
=== Overview ===<br />
<br />
This is a review of the include Firefox OS calendar app<br />
<br />
===Architecture===<br />
<br />
The Calendar App is a model-view-controller project based on the expressjs web application framework (http://expressjs.com/) <br />
<br />
provider - A provider object serves as a representation of the server state. Data generated by a provider will map to one or more local "stores". provider/abstract.js contains the API which providers /must/ implement.<br />
<br />
store - A store object maps an abstract set of data stores to the different db models. The API contract is defined in store/abstract.js . Providers and other calendar code interact with the DBs through the store API. The store is responsible for transforming calendar operations into a set of DB transactions / manipulations.<br />
<br />
db - The DBs used are IndexedDBs. db.js contains functions to open, close, upgrade and manipulate the underlying IndexedDB. This can be seen as the low level shim, whereas the store files operate at a higher level<br />
<br />
====Components====<br />
<br />
<br />
====Notes====<br />
3rd party library code in ext/ was not extensively reviewed<br />
<br />
<br />
====Relevant Source Code====<br />
<br />
Source code can be found at https://github.com/mozilla-b2g/gaia/tree/v1-train/apps/calendar<br />
<br />
====Permissions====<br />
<br />
"systemXHR":{},<br />
"settings":{ "access": "readonly" },<br />
"alarms":{},<br />
"desktop-notification":{}<br />
<br />
====Web Activity Handlers ====<br />
<br />
None<br />
<br />
==== System Messages ====<br />
<br />
"messages": [<br />
{ "alarm": "/index.html" }<br />
]<br />
<br />
The calendar installs a handler for the following:<br />
<br />
* alarm<br />
<br />
==== Notifications ====<br />
<br />
The app indirectly creates notifications through the alarm API.<br />
<br />
==== Post Messages ====<br />
<br />
The worker threads in worker/manager.js worker/thread.js use postMessage for communicating. This communication appears to be internal only. Also calendar.js uses postMessage but only responds to messages from itself.<br />
<br />
====Web Activity Usage ====<br />
<br />
None<br />
<br />
==== Notable Event Handlers ====<br />
<br />
===Code Review Notes===<br />
The calendar doesn't handle any web activities and has limited interaction with other apps. Calendar does extend the alarms API / db for non-phone devices.<br />
<br />
<br />
====1. XSS & HTML Injection attacks====<br />
<br />
None found. There two main injection vectors for the Calendar app<br />
1. user input when creating events<br />
2. Synced data from external calendars<br />
<br />
Manual entry of bad data into the Calendar app and syncing of bad data was performed. Template input is sufficiently escaped by the 'h' function in template.js . This function performs a regex check for HTML characters mathcing the regex /[&<>"'`]/ then escapes single and double-quotes. The corresponding template files in templates/ call either 'h', 's', 'bool' or 'l10n' to convert / escape data before display.<br />
<br />
====2. Secure Communications ====<br />
<br />
===== Remote Services =====<br />
<br />
The Calendar talks to remote servers. There are currently presets for the SSL versions of Google and Yahoo calendars. However a user may specify their own CalDav or Local calendar instance. There is some risk if the user specifies a HTTP endpoint instead of HTTPS. The app does not perform SSL certificate checks, however gecko will error on a certificate error.<br />
<br />
<br />
====3. (Secure) data storage ====<br />
<br />
All data is stored in one of a couple IndexedDBs. The code looks okay.<br />
<br />
<br />
====4. Denial of Service ====<br />
<br />
====5. Use of Privileged APIs ====<br />
<br />
====6. Interfaces with other Apps/Content====<br />
<br />
No interface is exposed to other applications.<br />
<br />
=== Security Risks & Mitigating Controls ===<br />
<br />
=== Actions & Recommendations ===</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/B2G/Reviews&diff=671126Security/B2G/Reviews2013-06-27T18:18:33Z<p>Dchan: /* Gecko Security Review Notes */</p>
<hr />
<div>===FirefoxOS Security Review Work===<br />
* List of current review bugs [https://bugzilla.mozilla.org/showdependencytree.cgi?id=754730&hide_resolved=1 Bug ].<br />
<bugzilla><br />
{<br />
"blocks": 754730,<br />
"resolution": "---",<br />
"include_fields": "id, priority, summary, status, assigned_to",<br />
"order": "priority,bug_id "<br />
}<br />
</bugzilla><br />
<br />
<br />
<br />
==== Gecko Security Review Notes ====<br />
Todo: gather links to all write ups.(If someone knows how to put the 'url' field in the above table, please do so.<br />
<br />
*[[Security/Reviews/Gaia/SystemMessageHandler]]<br />
*[[Security/Reviews/B2G/mozapp]]<br />
<br />
=== Gaia Reviews ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": 748190,<br />
"resolution": "---",<br />
"include_fields": "id, priority, summary, status, assigned_to",<br />
"order": "priority,bug_id "<br />
<br />
}<br />
</bugzilla><br />
<br />
==== Gaia Security Review Notes ====<br />
Don't forget to add <pre>[[Category:SecReview]]</pre> when creating pages so they show up in https://wiki.mozilla.org/Category:SecReview.<br />
<br />
==== Applications ====<br />
<br />
*[[Security/Reviews/Gaia/bluetooth]]<br />
*[[Security/Reviews/Gaia/browser]]<br />
*[[Security/Reviews/Gaia/calculator]]<br />
*[[Security/Reviews/Gaia/calendar]]<br />
*[[Security/Reviews/Gaia/Camera]]<br />
*[[Security/Reviews/Gaia/clock]]<br />
*[[Security/Reviews/Gaia/Communications]]<br />
*[[Security/Reviews/Gaia/costcontrol]]<br />
*[[Security/Reviews/Gaia/Contacts]]<br />
*[[Security/Reviews/Gaia/Dialer]]<br />
*[[Security/Reviews/Gaia/email]]<br />
*[[Security/Reviews/Gaia/feedback]]<br />
*[[Security/Reviews/Gaia/FacebookIntegration]]<br />
*[[Security/Reviews/Gaia/fm]]<br />
*[[Security/Reviews/Gaia/Gallery]]<br />
*[[Security/Reviews/Gaia/homescreen]]<br />
*[[Security/Reviews/Gaia/Keyboard]]<br />
*[[Security/Reviews/Gaia/Music]]<br />
*[[Security/Reviews/Gaia/pdfjs]]<br />
*[[Security/Reviews/Gaia/settings]]<br />
*[[Security/Reviews/Gaia/sms]]<br />
*[[Security/Reviews/Gaia/system]]<br />
*[[Security/Reviews/Gaia/Video]]<br />
*[[Security/Reviews/Gaia/wallpaper]]<br />
<br />
==== System (Components / Services) ====<br />
<br />
*[[Security/Reviews/Gaia/SystemMessageHandler]]</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/B2G/mozapp&diff=671123Security/Reviews/B2G/mozapp2013-06-27T18:17:30Z<p>Dchan: </p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=mozapp iframe<br />
|SecReview target=https://bugzilla.mozilla.org/show_bug.cgi?id=751026<br />
See also<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=750996<br />
https://bugzilla.mozilla.org/show_bug.cgi?id=750458<br />
}}<br />
{{SecReview<br />
|SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding.<br />
}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
|Feature version=FxOS 1.0<br />
}}<br />
===Technical details===<br />
<pre style="white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;"><br />
A non-standard attribute was added to the iframe tag called<br />
mozapp [1] This attribute allows a webpage to specify a manifest URL, that was previously pre-installed on the device or installed through window.navigator.mozApps.install [2]. A valid manifest meets the requirements set forth at [3] and may grant an app more privileges than a normal webpage has.<br />
<br />
A mozapp iframe must also have the mozbrowser attribute set. This is currently a limitation in the design of the feature and may be removed in the future. [4] <br />
<br />
This means that an embed mozapp iframe will have mozbrowser capabilities. [5] This is only relevant to the embeddor or the mozapp iframe, since it will be able to listen for certain events. Currently mozapp iframes are embedded by the System app which is fully trusted. <br />
<br />
Embedding a mozapp iframe requires the "embed-apps" permissions which is only given to certified apps. [6][7]<br />
<br />
Suffice to say, a user submitted app will never be able to create mozapp iframes under the current model. <br />
<br />
[1] - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe<br />
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Apps.install<br />
[3] - https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest<br />
[4] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l381<br />
[5] - https://developer.mozilla.org/en-US/docs/WebAPI/Browser<br />
[6] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l393<br />
[7] - http://hg.mozilla.org/mozilla-central/file/dd2ffe93fb2f/dom/apps/src/PermissionsTable.jsm#l208<br />
</pre><br />
===What does a mozapp iframe do?===<br />
<pre style="white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;"><br />
A mozapp iframe with a valid manifestURL and embeddor with proper permissions is granted the enhanced functionality of webapps. Permissions granted / denied are set when the app is installed. The biggest difference is the "origin" used when performing same origin checks. The gecko core was modified to use the concept of an extended origin defined as<br />
aExtendedOrigin = appId + "+" + { 't', 'f' } "+" + origin [1]<br />
<br />
appId: This is the appId for the supplied manifest, otherwise it is either NO_APP_ID or UNKNOWN_APP_ID [3]<br />
{'t', 'f,'}: This corresponds to whether this origin exists inside a mozBrowserFrame or not<br />
origin: This is the origin of the page / document. Note that the scheme will be app:// for packaged app resources<br />
<br />
This triple uniquely identifies the origin for cookies, session/localstorage and cross-origin checks. A mozapp iframe that is browsed to www.mozilla.org does not necessarily have the access to the cookies from a browser visiting www.mozilla.org . This can be due to the appIds being different and / or InMozBrowserFrame being different.<br />
<br />
<br />
[1] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/src/nsScriptSecurityManager.cpp#l2887<br />
[2] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/idl/nsIScriptSecurityManager.idl#l228<br />
</pre></div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/B2G/mozapp&diff=671120Security/Reviews/B2G/mozapp2013-06-27T18:13:26Z<p>Dchan: </p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=mozapp iframe<br />
|SecReview target=751026<br />
}}<br />
{{SecReview<br />
|SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding.<br />
}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
|Feature version=FxOS 1.0<br />
}}<br />
===Technical details===<br />
<pre><br />
A non-standard attribute was added to the iframe tag called<br />
mozapp [1] This attribute allows a webpage to specify a manifest URL, that was previously pre-installed on the device or installed through window.navigator.mozApps.install [2]. A valid manifest meets the requirements set forth at [3] and may grant an app more privileges than a normal webpage has.<br />
<br />
A mozapp iframe must also have the mozbrowser attribute set. This is currently a limitation in the design of the feature and may be removed in the future. [4] <br />
<br />
This means that an embed mozapp iframe will have mozbrowser capabilities. [5] This is only relevant to the embeddor or the mozapp iframe, since it will be able to listen for certain events. Currently mozapp iframes are embedded by the System app which is fully trusted. <br />
<br />
Embedding a mozapp iframe requires the "embed-apps" permissions which is only given to certified apps. [6][7]<br />
<br />
Suffice to say, a user submitted app will never be able to create mozapp iframes under the current model. <br />
<br />
[1] - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe<br />
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Apps.install<br />
[3] - https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest<br />
[4] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l381<br />
[5] - https://developer.mozilla.org/en-US/docs/WebAPI/Browser<br />
[6] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l393<br />
[7] - http://hg.mozilla.org/mozilla-central/file/dd2ffe93fb2f/dom/apps/src/PermissionsTable.jsm#l208<br />
</pre><br />
===What does a mozapp iframe do?===<br />
<pre><br />
A mozapp iframe with a valid manifestURL and embeddor with proper permissions is granted the enhanced functionality of webapps. Permissions granted / denied are set when the app is installed. The biggest difference is the "origin" used when performing same origin checks. The gecko core was modified to use the concept of an extended origin defined as<br />
aExtendedOrigin = appId + "+" + { 't', 'f' } "+" + origin [1]<br />
<br />
appId: This is the appId for the supplied manifest, otherwise it is either NO_APP_ID or UNKNOWN_APP_ID [3]<br />
{'t', 'f,'}: This corresponds to whether this origin exists inside a mozBrowserFrame or not<br />
origin: This is the origin of the page / document. Note that the scheme will be app:// for packaged app resources<br />
<br />
This triple uniquely identifies the origin for cookies, session/localstorage and cross-origin checks. A mozapp iframe that is browsed to www.mozilla.org does not necessarily have the access to the cookies from a browser visiting www.mozilla.org . This can be due to the appIds being different and / or InMozBrowserFrame being different.<br />
<br />
<br />
[1] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/src/nsScriptSecurityManager.cpp#l2887<br />
[2] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/idl/nsIScriptSecurityManager.idl#l228<br />
</pre></div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/B2G/mozapp&diff=671112Security/Reviews/B2G/mozapp2013-06-27T17:59:30Z<p>Dchan: </p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=mozapp iframe<br />
|SecReview target=751026<br />
}}<br />
{{SecReview<br />
|SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding.<br />
}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
|Feature version=FxOS 1.0<br />
}}<br />
===Technical details===<br />
<br />
A non-standard attribute was added to the iframe tag called<br />
mozapp [1] This attribute allows a webpage to specify a manifest URL, that was previously pre-installed on the device or installed through window.navigator.mozApps.install [2]. A valid manifest meets the requirements set forth at [3] and may grant an app more privileges than a normal webpage has.<br />
<br />
A mozapp iframe must also have the mozbrowser attribute set. This is currently a limitation in the design of the feature and may be removed in the future. [4] <br />
<br />
This means that an embed mozapp iframe will have mozbrowser capabilities. [5] This is only relevant to the embeddor or the mozapp iframe, since it will be able to listen for certain events. Currently mozapp iframes are embedded by the System app which is fully trusted. <br />
<br />
Embedding a mozapp iframe requires the "embed-apps" permissions which is only given to certified apps. [6][7]<br />
<br />
Suffice to say, a user submitted app will never be able to create mozapp iframes under the current model. <br />
<br />
[1] - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe<br />
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Apps.install<br />
[3] - https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest<br />
[4] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l381<br />
[5] - https://developer.mozilla.org/en-US/docs/WebAPI/Browser<br />
[6] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l393<br />
[7] - http://hg.mozilla.org/mozilla-central/file/dd2ffe93fb2f/dom/apps/src/PermissionsTable.jsm#l208<br />
<br />
===What does a mozapp iframe do?===<br />
<br />
separately keyed cookie / session storage / etc<br />
permissions associated with your manifest<br />
different origin<br />
extendedprincipal<br />
http://mxr.mozilla.org/mozilla-central/source/caps/src/nsScriptSecurityManager.cpp#2887<br />
2887 // aExtendedOrigin = appId + "+" + { 't', 'f' } "+" + origin;</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/B2G/mozapp&diff=671111Security/Reviews/B2G/mozapp2013-06-27T17:58:07Z<p>Dchan: Created page with "{{SecReviewInfo |SecReview name=mozapp iframe |SecReview target=751026 }} {{SecReview |SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding..."</p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=mozapp iframe<br />
|SecReview target=751026<br />
}}<br />
{{SecReview<br />
|SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding.<br />
|SecReview alt solutions=*Technical details*<br />
<br />
A non-standard attribute was added to the iframe tag called<br />
mozapp [1] This attribute allows a webpage to specify a manifest URL, that was previously pre-installed on the device or installed through window.navigator.mozApps.install [2]. A valid manifest meets the requirements set forth at [3] and may grant an app more privileges than a normal webpage has.<br />
<br />
A mozapp iframe must also have the mozbrowser attribute set. This is currently a limitation in the design of the feature and may be removed in the future. [4] <br />
<br />
This means that an embed mozapp iframe will have mozbrowser capabilities. [5] This is only relevant to the embeddor or the mozapp iframe, since it will be able to listen for certain events. Currently mozapp iframes are embedded by the System app which is fully trusted. <br />
<br />
Embedding a mozapp iframe requires the "embed-apps" permissions which is only given to certified apps. [6][7]<br />
<br />
Suffice to say, a user submitted app will never be able to create mozapp iframes under the current model. <br />
<br />
[1] - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe<br />
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Apps.install<br />
[3] - https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest<br />
[4] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l381<br />
[5] - https://developer.mozilla.org/en-US/docs/WebAPI/Browser<br />
[6] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l393<br />
[7] - http://hg.mozilla.org/mozilla-central/file/dd2ffe93fb2f/dom/apps/src/PermissionsTable.jsm#l208<br />
<br />
*What does a mozapp iframe do?*<br />
}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
|Feature version=FxOS 1.0<br />
}}</div>Dchanhttps://wiki.mozilla.org/index.php?title=MoPal&diff=665010MoPal2013-06-07T20:44:29Z<p>Dchan: </p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=MoPal (Elastic Search Query Tool)<br />
|SecReview target={{bug|880410}}<br />
}}<br />
{{SecReview}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
}}</div>Dchanhttps://wiki.mozilla.org/index.php?title=MoPal&diff=665009MoPal2013-06-07T20:44:07Z<p>Dchan: Created page with "{{SecReviewInfo |SecReview name=MoPal (Elastic Search Query Tool) |SecReview target=880410 }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}"</p>
<hr />
<div>{{SecReviewInfo<br />
|SecReview name=MoPal (Elastic Search Query Tool)<br />
|SecReview target=880410<br />
}}<br />
{{SecReview}}<br />
{{SecReviewActionStatus<br />
|SecReview action item status=None<br />
}}</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Web_Bug_Rotation&diff=616785Security/Web Bug Rotation2013-03-13T21:26:15Z<p>Dchan: /* Process */</p>
<hr />
<div>=Web Bug Verification=<br />
When bugs are reported to the security@Mozilla.org mailbox is often necessary to verify the reported vulnerability before passing the bug on to developers. This verification work is shared by several members of the security assurance team is a weekly rotation. The following pages meant to document the procedures for verification and to serve as a reminder for those "on call for the week"as to the procedures that need to be completed. In general bugs will have an attempt to verify them in approximately 1 working day.<br />
<br />
=Process=<br />
<br />
Under {{bug|835475}} (web-bounty), you will find a list metabugs for different Mozilla web properties. The list is ad-hoc<br />
and likely needs to be expanded. There is currently a catch all {{bug|836522}} (other-bounty) to cover bugs that do not fit<br />
into any of the other trackers.<br />
<br />
# New bugs reported to the security@ alias or filed directly will have the whiteboard marked with [verif?] to designate them as needing verification. They shall also have the status of unconfirmed.<br />
# The bug will be assigned to the security assurance member listed on the security assurance calendar is the on-call rotation for that week.<br />
# Verification assignee determines if the issue reported is NEW, INVALID, or DUPLICATE<br />
#* '''DUPLICATE''' (via general bugzilla search or via existing meta bugs)<br />
## Dupe against old bug<br />
## Set keywords & whiteboard for the new duped bug<br />
##* Whiteboard - [site:example.com] <br />
##**<i>set to site being reported</i><br />
##* Keywords - wsec-<br />
##** <i>set to appropriate keyword for type of issue being reported</i><br />
## Set "sec-bounty" flag to "-" on new bug since it was a dupe<br />
## Set the new bug blocking the appropriate metabug(s)<br />
#* For older bugs duped against that do not have the current flags<br />
## If the old bug has the attachment 'bounty non-qual' or similar then set sec-bounty- on the old bug<br />
## If the old bug has the attachment 'bounty awarded X' or 'bounty paid X', then set sec-bounty+ on the old bug<br />
## If no duplicate is found and the issue is not verified the bug shall be RESOLVED - INVALID and the whiteboard tag removed.<br />
#* '''NEW'''<br />
## Remove [verif?] from the whiteboard<br />
## Set keywords & whiteboard for the new duped bug<br />
##* Whiteboard - [site:example.com] <br />
##**<i>set to site being reported</i><br />
##* Keywords - wsec-<br />
##** <i>set to appropriate keyword for type of issue being reported</i><br />
## Set "sec-bounty" flag to "?" <br />
## Change "Status" shall be set to "NEW" to show bug is verified<br />
## Block the appropriate meta-bug<br />
## Edit "Assigned To" and check the box for "Reset Assignee to default"<br />
#* '''INVALID'''<br />
## Resolve bug as invalid</div>Dchanhttps://wiki.mozilla.org/index.php?title=Security/Reviews/Gaia/Calendar&diff=538355Security/Reviews/Gaia/Calendar2013-03-08T02:04:40Z<p>Dchan: Created page with "=== App Review Details === * App: Calendar * Original Review Date: 09 Jan 2013 * Follow-up Review Data: 25 Feb 2013 * Review Lead: David Chan * Review Bug: {{bug|754736}} [Secu..."</p>
<hr />
<div>=== App Review Details ===<br />
<br />
* App: Calendar<br />
* Original Review Date: 09 Jan 2013<br />
* Follow-up Review Data: 25 Feb 2013<br />
* Review Lead: David Chan<br />
* Review Bug: {{bug|754736}} [Security Review] B2G Gaia - Calendar<br />
* Dependency Tree: https://bugzilla.mozilla.org/showdependencytree.cgi?id=754736&hide_resolved=0<br />
<br />
=== Overview ===<br />
<br />
This is a review of the include Firefox OS calendar app<br />
<br />
===Architecture===<br />
<br />
The Calendar App is a model-view-controller project based on the expressjs web application framework (http://expressjs.com/) <br />
<br />
provider - A provider object serves as a representation of the server state. Data generated by a provider will map to one or more local "stores". provider/abstract.js contains the API which providers /must/ implement.<br />
<br />
store - A store object maps an abstract set of data stores to the different db models. The API contract is defined in store/abstract.js . Providers and other calendar code interact with the DBs through the store API. The store is responsible for transforming calendar operations into a set of DB transactions / manipulations.<br />
<br />
db - The DBs used are IndexedDBs. db.js contains functions to open, close, upgrade and manipulate the underlying IndexedDB. This can be seen as the low level shim, whereas the store files operate at a higher level<br />
<br />
====Components====<br />
<br />
<br />
====Notes====<br />
3rd party library code in ext/ was not extensively reviewed<br />
<br />
<br />
====Relevant Source Code====<br />
<br />
Source code can be found at https://github.com/mozilla-b2g/gaia/tree/v1-train/apps/calendar<br />
<br />
====Permissions====<br />
<br />
"systemXHR":{},<br />
"settings":{ "access": "readonly" },<br />
"alarms":{},<br />
"desktop-notification":{}<br />
<br />
====Web Activity Handlers ====<br />
<br />
None<br />
<br />
==== System Messages ====<br />
<br />
"messages": [<br />
{ "alarm": "/index.html" }<br />
]<br />
<br />
The calendar installs a handler for the following:<br />
<br />
* alarm<br />
<br />
==== Notifications ====<br />
<br />
The app indirectly creates notifications through the alarm API.<br />
<br />
==== Post Messages ====<br />
<br />
The worker threads in worker/manager.js worker/thread.js use postMessage for communicating. This communication appears to be internal only. Also calendar.js uses postMessage but only responds to messages from itself.<br />
<br />
====Web Activity Usage ====<br />
<br />
None<br />
<br />
==== Notable Event Handlers ====<br />
<br />
===Code Review Notes===<br />
The calendar doesn't handle any web activities and has limited interaction with other apps. Calendar does extend the alarms API / db for non-phone devices.<br />
<br />
<br />
====1. XSS & HTML Injection attacks====<br />
<br />
None found. There two main injection vectors for the Calendar app<br />
1. user input when creating events<br />
2. Synced data from external calendars<br />
<br />
Manual entry of bad data into the Calendar app and syncing of bad data was performed. Template input is sufficiently escaped by the 'h' function in template.js . This function performs a regex check for HTML characters mathcing the regex /[&<>"'`]/ then escapes single and double-quotes. The corresponding template files in templates/ call either 'h', 's', 'bool' or 'l10n' to convert / escape data before display.<br />
<br />
====2. Secure Communications ====<br />
<br />
===== Remote Services =====<br />
<br />
The Calendar talks to remote servers. There are currently presets for the SSL versions of Google and Yahoo calendars. However a user may specify their own CalDav or Local calendar instance. There is some risk if the user specifies a HTTP endpoint instead of HTTPS. The app does not perform SSL certificate checks, however gecko will error on a certificate error.<br />
<br />
<br />
====3. (Secure) data storage ====<br />
<br />
All data is stored in one of a couple IndexedDBs. The code looks okay.<br />
<br />
<br />
====4. Denial of Service ====<br />
<br />
====5. Use of Privileged APIs ====<br />
<br />
====6. Interfaces with other Apps/Content====<br />
<br />
No interface is exposed to other applications.<br />
<br />
=== Security Risks & Mitigating Controls ===<br />
<br />
=== Actions & Recommendations ===</div>Dchanhttps://wiki.mozilla.org/index.php?title=Marketplace/API/CSRF&diff=529699Marketplace/API/CSRF2013-02-26T02:23:41Z<p>Dchan: /* Persona clients */</p>
<hr />
<div>== CSRF ==<br />
<br />
The Marketplace (and AMO) in 2012 had a standard flow for CSRF protection. Client GETs the page from the server. Page includes a CSRF token which is tied to the users session on the server. Client POSTs a form with a CSRF token in it, we check the two match and process the request.<br />
<br />
However, The Marketplace is being re-written as a packaged app. This means that there may never be that original get to the server to request a CSRF token in the form. The user will browse the app and POST a comment or the rating to the API and never send a CSRF token. How do we prevent abuse of these APIs? This might not matter as much for ratings and comments, but will when the API is extended to include reviewer tools, management tools and so on.<br />
<br />
== OTP ==<br />
<br />
One suggestion is OTP: http://tools.ietf.org/html/rfc6238<br />
<br />
=== Persona clients ===<br />
<br />
* When persona authentication is performed both the client and server keep a hash of the assertion<br />
** [dchan] - Is a hash of the assertion needed? Is this an implementation detail to make sure the assertion is the proper size for keying the algorithm?<br />
* That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request.<br />
** [dchan] - Should we add in some additional random / session data to prevent two identical assertions from generating the same HTOP sequence? I don't think it matters in practice since the expiration time /should/ be different for each generated assertion. The concern being if some bad implementation always set the assertion expiration time to the same e.g end of year.<br />
* Clients will send the correct HOTP, the server will compare its token using the seed.<br />
<br />
What to do about anonymous?<br />
** [dchan] - Captcha may be sufficient. The UX likely isn't ideal in this case.<br />
<br />
=== Non-Persona clients ===<br />
<br />
(e.g. Python servers)<br />
<br />
* Can use a hash of the oAuth token for its seed, since we'll assume they'll have to use oAuth anyway.<br />
* That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request.<br />
* Clients will send the correct HOTP, the server will compare its token using the seed.<br />
<br />
Assume no anonymous access.<br />
<br />
=== HOTP or TOTP ===<br />
<br />
The difference between HOTP and TOTP lies in synchronization strategy. HOTP relies on the server and client maintaining counters that stay synchronized. TOTP uses time instead of a counter, and thus relies on clients and servers being synchronized in time.<br />
<br />
Both protocols provide a way to handle desynchronization; the RFC's recommendation is to allow a resynchronization window of fixed size, beyond which repeating the authorization step would be necessary. The difference is that desynchronization in HOTP is based on number of messages the client sends that the server misses, and in TOTP is based on clock skew between client and server.<br />
<br />
=== Different security zones ===<br />
<br />
We also have to realise that different APIs might have different security requirements. As mentioned comments and ratings are of lower concern than reviewer and admin APIs. Perhaps we need to have a set of zones or rules to evaluate APIs and ensure that different APIs have different requirements. For example:<br />
<br />
<strong>DRAFT</strong><br />
<br />
{|<br />
|API||Auth||OTP||CORs<br />
|-<br />
|Comments||No||Yes||Yes<br />
|-<br />
|Reviewing||Yes||Yes||No<br />
|}</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-07-03&diff=447325Services/Meetings/2012-07-032012-07-03T16:15:08Z<p>Dchan: </p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': <br />
* dchan - out next week with limited mail availability<br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
<br />
* Sentry server added to vagrant-metlog-backend<br />
* released new logstash-metlog 0.8 RPMs for sync and aitc<br />
* New updates to JSON log push to HDFS fro metlog<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
* worked through zmq/gevent build issues<br />
* AITC release 1.2 deployed to production \o/<br />
* Sync1.1 catchup release passed load test<br />
* Sync1.1 + Metlog release tagged for loadtesting and deployment (https://bugzilla.mozilla.org/show_bug.cgi?id=770406)<br />
* substantial work on refactoring syncstorage backends for transactions/atomicity<br />
<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* Update Queuey to support Cassandra 1.1<br />
* Improve pycassa's C* 1.1 support and other improvements (5 open pull requests)<br />
* Ported lock and leader election recipes to kazoo<br />
* More documentation on usage and Zookeeper<br />
<br />
=== Token Server & other french stuff (tarek/alexis) ===<br />
=== Signing (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* My updates belong to Firefox now<br />
* {{bug|763171}} fix receive tab implementation<br />
* {{bug|732152}} implement generic JS client for storage service 2.0<br />
* {{bug|760466}} make JS storage service server 2.0 pass all python functional tests<br />
* {{bug|755339}} testing-only JS modules foo<br />
* {{bug|762837}} testing-only JS modules foo<br />
* {{bug|755196}} allow httpd.js to be loaded as a module<br />
* {{bug|757860}} refactor HTTP servers in services/ to be loaded as modules<br />
<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
* Continued client discussions with rnewman<br />
* Building out server controls for plugin (needed for stand alone demo)<br />
<br />
== Tools ==<br />
=== Circus (tarek/alexis/nick) ===<br />
* Nick started the implementation of secure connections (ssl) on top of ZMQ using paramiko and ssh tunnels.<br />
* Sockets are now in circus, we wrote some benchs (http://blog.ziade.org/2012/06/28/wgsi-web-servers-bench/) and gathered feedback;<br />
* Added support for socket stats in the web interface<br />
* Circus 0.5 incoming (today ot tomorrow).<br />
* We have some contributions and people using circus, which is a good thing.<br />
* Working on an interactive shell for circus<br />
<br />
=== Flemmard (tarek/alexis) ===<br />
=== Cornice (tarek/alexis) ===<br />
<br />
* working on documentation generation and curl-like request/response automatically generated to put there.<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
== Sync Server (jbonacci/jrgm) ==<br />
* QA testing continues on Sync 1.1, Sync 1.1+MetLog<br />
* QA testing continues on Sync 2.0<br />
* Working on Resolved/Fixed bugs for Sync 1.1, Sync 2.0, AITC 1.2, TokenServer 1.1<br />
* QA test planning for HSM/Signing Service<br />
* Various other projects to support QA team, OPs, Dev<br />
<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Bug 767708 - QA and deploy BrowserID train-2012.06.22 to production <br />
** Deployment has been moved from this to Monday, July 9<br />
* QA test planning for Big Tent<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Firefox 17 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-06-19&diff=442973Services/Meetings/2012-06-192012-06-19T16:17:00Z<p>Dchan: /* Security (dchan) */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': <br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
* Functional testing against dev servers for metlog-enabled AitC and Sync 1.1 servers<br />
* Debugging and tweaking logstash behavior, configuration, and output on AitC and Sync 1.1 dev servers<br />
* Testing / fixes w/ getting gevent to work w/ metlog's ZeroMQ sender<br />
* Improved metlog-py's superficial b/w compatibility w/ stdlib logging module API<br />
* Started conversation w/ legal re: potential privacy issues w/ recent data gathering requests<br />
* RPM building for upcoming deployments<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
<br />
* Added ability to run sync1.1 functional tests against a live server<br />
* Several tweaks to still-in-progress deployment of latest Sync1.1 code (https://bugzilla.mozilla.org/show_bug.cgi?id=761068)<br />
* Refactored mozsvc.user to remove dependency on repoze.who<br />
* Final tweaks for imminent AITC production deployment (waiting on https://bugzilla.mozilla.org/show_bug.cgi?id=750566)<br />
<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* [queuey] Added new API to PUT messages with application-supplied message keys<br />
* [queuey] Enjoy a good deal of debugging a test failure caused by float precision issues vs. UUID1 precision<br />
* [kazoo] Added a larger suite of unit tests<br />
* [kazoo] Start importing txzookeeper ensemble testing for session expiration tests<br />
<br />
=== Token Server & other french stuff (tarek/alexis) ===<br />
<br />
* Released Circus 0.4 last week. see http://blog.ziade.org/2012/06/12/circus-04-released/<br />
* Started working on CI/CT<br />
* Continuing to work on Circus, playing with sockets (into other things)<br />
* We have an intern who will be working on Circus clustering mechanisms, see https://github.com/mozilla-services/circus/issues/112<br />
<br />
=== Signing (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Small AITC reviews<br />
* Notifications boilerplate is checked into s-c<br />
** Turned tree orange. I have a review to build team outstanding. Will revert if don't get it soon. No big deal, since Notifications isn't shipping... yet<br />
* Submitted a few Firefox Sync reviews to rnewman<br />
* Still trying to land testing-only JS modules ({{bug|762837}}) and related refactorings<br />
** Weird Windows-only failure on build hosts. 15 Try builds and counting!<br />
* 42<br />
<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
<br />
* liuche in Iceland last weekend<br />
* rnewman on the road to California<br />
* moving on 15 P1s: https://bugzilla.mozilla.org/buglist.cgi?priority=P1;classification=Client%20Software;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;component=Android%20Sync;product=Mozilla%20Services;list_id=3463375<br />
* Fennec release Real Soon Now<br />
* Final Call for objections to shipping Native Fennec is today. :ally<br />
<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
* More meetin's (This time with bizdev and engineering overview.)<br />
* jbalogh - <br />
<br />
* jr - <br />
** Working on crypto issue<br />
** Working on server in a box (for business dev)<br />
** continuing work on notification plugin (notif. management)<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
* no client trains<br />
<br />
== Sync Server (jbonacci/jrgm) ==<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Current focus is here:<br />
** Train 29: Bug 763105 - QA and deploy BrowserID train-2012.06.08 to production<br />
*** https://bugzilla.mozilla.org/show_bug.cgi?id=763105<br />
*** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120613<br />
*** Bug 763586 - Develop puppet scripts to accommodate new "router" process in browserid train-2012.06.08<br />
* There are discussions about delaying/derailing current train due to changes for router in Stage (and ultimately in Prod).<br />
** See the following thread:<br />
*** "BrowserID train 2012.06.08 deploy to production delayed by +7 days"<br />
* QA backs OPs decision for more time on router work, and the necessary continued testing in Stage and Prod for router support<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Firefox 17 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
* finishing up Notifications review items<br />
* dchan out 7-4 to 7-13<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-06-19&diff=442972Services/Meetings/2012-06-192012-06-19T16:16:14Z<p>Dchan: /* Security (dchan) */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': <br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
* Functional testing against dev servers for metlog-enabled AitC and Sync 1.1 servers<br />
* Debugging and tweaking logstash behavior, configuration, and output on AitC and Sync 1.1 dev servers<br />
* Testing / fixes w/ getting gevent to work w/ metlog's ZeroMQ sender<br />
* Improved metlog-py's superficial b/w compatibility w/ stdlib logging module API<br />
* Started conversation w/ legal re: potential privacy issues w/ recent data gathering requests<br />
* RPM building for upcoming deployments<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
<br />
* Added ability to run sync1.1 functional tests against a live server<br />
* Several tweaks to still-in-progress deployment of latest Sync1.1 code (https://bugzilla.mozilla.org/show_bug.cgi?id=761068)<br />
* Refactored mozsvc.user to remove dependency on repoze.who<br />
* Final tweaks for imminent AITC production deployment (waiting on https://bugzilla.mozilla.org/show_bug.cgi?id=750566)<br />
<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* [queuey] Added new API to PUT messages with application-supplied message keys<br />
* [queuey] Enjoy a good deal of debugging a test failure caused by float precision issues vs. UUID1 precision<br />
* [kazoo] Added a larger suite of unit tests<br />
* [kazoo] Start importing txzookeeper ensemble testing for session expiration tests<br />
<br />
=== Token Server & other french stuff (tarek/alexis) ===<br />
<br />
* Released Circus 0.4 last week. see http://blog.ziade.org/2012/06/12/circus-04-released/<br />
* Started working on CI/CT<br />
* Continuing to work on Circus, playing with sockets (into other things)<br />
* We have an intern who will be working on Circus clustering mechanisms, see https://github.com/mozilla-services/circus/issues/112<br />
<br />
=== Signing (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Small AITC reviews<br />
* Notifications boilerplate is checked into s-c<br />
** Turned tree orange. I have a review to build team outstanding. Will revert if don't get it soon. No big deal, since Notifications isn't shipping... yet<br />
* Submitted a few Firefox Sync reviews to rnewman<br />
* Still trying to land testing-only JS modules ({{bug|762837}}) and related refactorings<br />
** Weird Windows-only failure on build hosts. 15 Try builds and counting!<br />
* 42<br />
<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
<br />
* liuche in Iceland last weekend<br />
* rnewman on the road to California<br />
* moving on 15 P1s: https://bugzilla.mozilla.org/buglist.cgi?priority=P1;classification=Client%20Software;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;component=Android%20Sync;product=Mozilla%20Services;list_id=3463375<br />
* Fennec release Real Soon Now<br />
* Final Call for objections to shipping Native Fennec is today. :ally<br />
<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
* More meetin's (This time with bizdev and engineering overview.)<br />
* jbalogh - <br />
<br />
* jr - <br />
** Working on crypto issue<br />
** Working on server in a box (for business dev)<br />
** continuing work on notification plugin (notif. management)<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
* no client trains<br />
<br />
== Sync Server (jbonacci/jrgm) ==<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Current focus is here:<br />
** Train 29: Bug 763105 - QA and deploy BrowserID train-2012.06.08 to production<br />
*** https://bugzilla.mozilla.org/show_bug.cgi?id=763105<br />
*** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120613<br />
*** Bug 763586 - Develop puppet scripts to accommodate new "router" process in browserid train-2012.06.08<br />
* There are discussions about delaying/derailing current train due to changes for router in Stage (and ultimately in Prod).<br />
** See the following thread:<br />
*** "BrowserID train 2012.06.08 deploy to production delayed by +7 days"<br />
* QA backs OPs decision for more time on router work, and the necessary continued testing in Stage and Prod for router support<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Firefox 17 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
* finishing up Notifications review items<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-06-12&diff=440367Services/Meetings/2012-06-122012-06-12T16:21:52Z<p>Dchan: /* Security (dchan) */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': <br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
* Metlog support integrated into latest versions of server-core / server-storage <br />
* lots of work on Metlog back end Vagrant VM set up<br />
* backwards compatibility shim from Metlog -> stdlib logging module for use by people running external sync servers<br />
* testing of Metlog message delivery in dev environment for both sync 1.1 and AitC<br />
* meeting w/ Andy McKay (from WebDev) and Anurag Phadke (from Metrics) re: gathering of specific AitC metrics<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* [qdo] Added API to handle job failures and integrate metlog-raven to log exceptions<br />
<br />
=== Token Server (tarek/alexis) ===<br />
=== Signing (rtilder) ===<br />
* Working with jbonacci and atoll to get them up to speed prior to release on the 22nd<br />
<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
<br />
* cranking on as many user facing tickets as we can<br />
* rnewman heroically landed Send Tab to Device on Friday last<br />
* beta period almost over<br />
* building a plan to address support for multiple Firefox versions.<br />
<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
* Introductory meeting w/ bizdev and product.<br />
* need to rework goals and priorities based on input.<br />
* working on server crypto libraries for php/perl<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
* open issue: {{Bug|763252}} - Firefox Sync lead to memory leaks<br />
* no client trains recently<br />
<br />
== Sync Server (jbonacci/jrgm) ==<br />
* Sync 1.1 functional testing is in progress<br />
* Sync 1.1 support for MetLog - testing continues in Dev/Stage<br />
* AITC 1.1 + MetLog support<br />
* HSM Dev/OPs/QA planning meeting this week<br />
* Sync 1.1, AITC 1.1 bug verification planned for this week and next<br />
* AITC/TC deploy to Prod still planned<br />
** Debug/Issue resolution still happening in Stage<br />
<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Train 29<br />
** Bug 763105 - QA and deploy BrowserID train-2012.06.08 to production<br />
** Bug 763586 - Develop puppet scripts to accommodate new "router" process in browserid train-2012.06.08<br />
* Big Tent (IdProxy) test planning continues<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Firefox 17 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
* Notifications review this Thursday (2012-06-14) 10 AM Pacific<br />
* Location: SFO 7N, MV Sickbay <br />
* Vidyo room: 624 (Curtis Koenig) <br />
* Dial in: x9624<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-06-12&diff=440366Services/Meetings/2012-06-122012-06-12T16:21:22Z<p>Dchan: /* Security (dchan) */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': <br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
* Metlog support integrated into latest versions of server-core / server-storage <br />
* lots of work on Metlog back end Vagrant VM set up<br />
* backwards compatibility shim from Metlog -> stdlib logging module for use by people running external sync servers<br />
* testing of Metlog message delivery in dev environment for both sync 1.1 and AitC<br />
* meeting w/ Andy McKay (from WebDev) and Anurag Phadke (from Metrics) re: gathering of specific AitC metrics<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* [qdo] Added API to handle job failures and integrate metlog-raven to log exceptions<br />
<br />
=== Token Server (tarek/alexis) ===<br />
=== Signing (rtilder) ===<br />
* Working with jbonacci and atoll to get them up to speed prior to release on the 22nd<br />
<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
<br />
* cranking on as many user facing tickets as we can<br />
* rnewman heroically landed Send Tab to Device on Friday last<br />
* beta period almost over<br />
* building a plan to address support for multiple Firefox versions.<br />
<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
* Introductory meeting w/ bizdev and product.<br />
* need to rework goals and priorities based on input.<br />
* working on server crypto libraries for php/perl<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
* open issue: {{Bug|763252}} - Firefox Sync lead to memory leaks<br />
* no client trains recently<br />
<br />
== Sync Server (jbonacci/jrgm) ==<br />
* Sync 1.1 functional testing is in progress<br />
* Sync 1.1 support for MetLog - testing continues in Dev/Stage<br />
* AITC 1.1 + MetLog support<br />
* HSM Dev/OPs/QA planning meeting this week<br />
* Sync 1.1, AITC 1.1 bug verification planned for this week and next<br />
* AITC/TC deploy to Prod still planned<br />
** Debug/Issue resolution still happening in Stage<br />
<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Train 29<br />
** Bug 763105 - QA and deploy BrowserID train-2012.06.08 to production<br />
** Bug 763586 - Develop puppet scripts to accommodate new "router" process in browserid train-2012.06.08<br />
* Big Tent (IdProxy) test planning continues<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Firefox 17 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
Notifications review this Thursday (2012-06-14) 10 AM Pacific<br />
Location: SFO 7N, MV Sickbay <br />
Vidyo room: 624 (Curtis Koenig) <br />
Dial in: x9624<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-05-29&diff=435120Services/Meetings/2012-05-292012-05-29T16:11:54Z<p>Dchan: /* Security (dchan) */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': Tracy PTO May 26th - June 3rd<br />
<br />
= Ops =<br />
== Hardware ==<br />
== Projects ==<br />
== Other Notes ==<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller/vng) ===<br />
<br />
* updated vagrant-centos to have a working statsd/graphite-web/logstash backend<br />
<br />
=== SyncStorage/AITC (rfkelly) ===<br />
<br />
* Fixed several more bugs/docs problems with run-your-own sync server<br />
* Sync1.1 branch merging and other groundwork for deploying a metlog-enabled version<br />
* Getting AITC loadtesting back on track. Currently see sharply increasing error rate with load above ~150 RPS, need to dig into what's happening in the database.<br />
<br />
=== Queuey (bbangert/hannosch) ===<br />
<br />
* [zookeeper] First merge of kazoo/zc.zk/zktools code into single kazoo code-base<br />
* [zookeeper] Next, to update docs, verify working base client behavior, integrate testing<br />
* [bbangert] Became very familiar with limitations of gevent/threading coordination objects<br />
<br />
=== Token Server (tarek/alexis) ===<br />
<br />
* weird bug should be gone now - observation phase today & tomorrow<br />
* adding tools for nagios monitoring of the token server this week<br />
* changing the loadtesting suite to use mockmyid.com baked assertions rather than being in a loadtest mode.<br />
<br />
=== Signing (rtilder) ===<br />
<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* 5 day weekend to celebrate birthday. Doing it right.<br />
* Wrestling with AITC JS server<br />
** Someone please fix the Python builds. I'm getting timeouts installing packages, inability to CTRL-C, etc. It is blocking me from running the Python functional tests against the server and this is blocking AITC client testing.<br />
* Started look at AITC Manager review<br />
* Sync broken on SpiderMonkey {{bug|758530}}<br />
<br />
=== Android Sync (rnewman/nalexander/liuche) ===<br />
<br />
5-day weekend to celebrate gps's birthday. Well, just because.<br />
<br />
== Notifications ==<br />
=== Client/Server (jbalogh/jrconlin) ===<br />
<br />
= QA =<br />
== Client Testing and Sign-offs (tracy) ==<br />
<br />
== Sync Server (jbonacci/jrgm) ==<br />
* Continued support to Dev and OPs for various deployments<br />
* Working with Ryan on AITC 1.1 in Stage<br />
** Tracking this work for push to Production (part of BaseCamp)<br />
* Working with Ryan and Robert on Sync 1.1 plus MetLog support for Stage/Production<br />
** Bug 758482 - [meta] build and deploy a metlog-enabled sync1.1 server<br />
* Working through some docs for AITC and TokenServer<br />
* Test planning for HSM<br />
** Bug 756664 - Metabug for HSM/signing service transition<br />
* Tracking AITC client side for BaseCamp<br />
** Bug 757261 - Implement AITC manager and service<br />
<br />
== BrowserID (jrgm/jbonacci) ==<br />
* Test prep for Train 28<br />
** Bug 758840 - QA and deploy BrowserID train-2012.05.25 to production<br />
* Test prep for BigTent deployment to Stage environment<br />
* Test planning continues for the following:<br />
** Updated API, UI flow, RP, Keywrapping<br />
** Persona Beta<br />
* Consulting for the following projects:<br />
** VinzClortho (BID support in Mozilla.com/.org)<br />
** KPI (UX metrics)<br />
* BID Automation<br />
** The WebQA team continuing to increase coverage of platforms<br />
** Latest info: https://wiki.mozilla.org/Identity/QA#Automation<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 13 ===<br />
=== Firefox 14 ===<br />
=== Firefox 15 ===<br />
=== Firefox 16 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
* Tokenserver review slipped<br />
* Simon Bennetts will help with services security work<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== Notes and actions ==<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408618Apps/Security2012-03-16T20:24:11Z<p>Dchan: /* Definitions */</p>
<hr />
<div>= Boot 2 Gecko App Security Model Discussion =<br />
This page is for capturing information about the B2G/OWA security discussion. <br />
{{note|<b>This is not a design document and should not be considered authoritative at this time</b>}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
* '''Extended Validation (EV) Certificate''' - A SSL certificate that undergoes additional authentication / verification steps before issuance.<br />
** [http://www.cabforum.org/certificates.html Explanation]<br />
** [http://www.cabforum.org/vetting.html Verification process]<br />
* '''Content Security Policy (CSP)''' - A mechanism by which website administrators can define a policy which restricts what domains a website can load resources from<br />
** [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html Specification]<br />
'''Important reading!''' B2G applications are Open Web Apps, you can read about them here: https://developer.mozilla.org/en-US/apps<br />
<br />
=== Concepts to be given Official Definitions ===<br />
<br />
There is no real easy way to distinguish the following, all of which are iframes (!) in the B2G environment. There is some considerable confusion as a result, especially due to the fact that the required security context and especially the interactions between parent and child iframes are ''different'' depending on the type of iframe.<br />
<br />
Names really therefore need to be given to the following:<br />
<br />
* the root frame (top-level one into which the top gaia HTML is loaded)<br />
* individual gaia apps (sub-iframes, one per app)<br />
* any gaia app that opens up a public-facing (URL-based) iframe in which the contents of a URI are displayed: the browser app is one such<br />
* iframes *within* that iframe - as in "iframes that you normally think of iframes being used for as an ordinary web developer".<br />
<br />
Discussion which raises the issue of confused definitions, helps clarify them:<br />
https://groups.google.com/d/msg/mozilla.dev.b2g/AQYPkIjKxjE/WYy0LPta9cMJ<br />
<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices. (an analogy in debian packaging terms is that the telco sets the initial contents of the /etc/apt/sources.list file)<br />
<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* {{note|Last updated March 14, 2012}}<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] and SELinux for enforcing permissions ===<br />
<br />
The Flask Architecture makes it possible to implement various Access Control systems. SELinux is technically an implementation of Mandatory access control based on Flask Architecture.<br />
<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs in the current implementation is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
Full Discussion on NSA's SE-Linux Mailing List:<br />
http://marc.info/?l=selinux&m=133190422130989&w=2<br />
<br />
Summary points of Discussion on NSA's SE-Linux Mailing List:<br />
<br />
* As B2G is based on Android, it may be worthwhile investigating http://selinuxproject.org/page/SEAndroid<br />
** Apart from anything it will save time on developing the base permission set (to cover the main OS)<br />
** SE-Android is being developed by the NSA ''specifically'' to avoid the need for Android developers to get involved with the "low-level" SE-Linux permissions system.<br />
* ''Stephen Smalley (NSA) has the following recommendation'': See http://www.nsa.gov/research/selinux/related.shtml for some links to work done to apply Flask to various other applications like PostgreSQL, Xorg, and D-BUS.<br />
** Following Stephen's recommendation would allow the creation of very special permissions that are specifically relevant to B2G, for proper enforcement at the Linux Kernel level.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
==== dealing with rogue applications ====<br />
<br />
this section covers how an application may be replaced if discovered to be malicious<br />
<br />
* automatic updates must be enabled (apt-get upgrade)<br />
* people who wish to remain on a "stable" store must have a security-line equivalent to "deb http://security.debian.org/.... "<br />
* rogue applications have a package with a version number "1 higher" than the rogue application's previous package<br />
* the updated package can:<br />
** be a properly bug-fixed version<br />
** contain warnings that the user must explicitly agree to prior to acceptance<br />
** in extreme cases simply replace the files with a blank app that announces "This Application Caused Serious Problems, It Had To Go, Make Sure You Check Your Data N System N Stuff".<br />
<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
==== Kernel permissions manager ====<br />
<br />
{lkcl.15mar12.2223hrs - it's not clear to me what this section refers to: a userspace application that interacts with the user to help them select the level of access that they wish to grant to a particular application, or to the actual kernel-side implementation that enforces the permissions, or a developer "assistance" suite of software which helps the developer to create the permission set that's to be associated with the application when it's installed}<br />
<br />
* separate process that controls access to permissions<br />
* responsible for<br />
*# query permissions, true/false if permissions X is granted<br />
*#* support for prompting user in event permission isn't granted<br />
*# add / remove permissions<br />
*# audit permissions<br />
*# support observers for permission change<br />
* permissions requested are based on "uri signatures"<br />
** to be determined what the signature is: domain, partial url, other?<br />
* permissions representation<br />
** type - usb, web, radio, etc<br />
** uri signature<br />
** value<br />
** source - user, manifest, system<br />
** expiration type - never, time-based, session, other?<br />
** expiration time<br />
** allow message - for UI / prompting user <br />
** deny message<br />
* app obtains permission by querying / asking central process<br />
* OS support required for properly constructing signature, app should not be able to influence this<br />
** there needs to be a unique identifier than an app can't spoof<br />
* permissions requests can be cached<br />
** cache needs to be invalidated on permission change<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
==== The Problem With Using SSL ====<br />
<br />
One problem is that SSL (when used with PKI Certificates for Authentication) is that the solution becomes the problem. When a device may '''only''' download from a site over HTTPS where only those devices which have the appropriate public key may connect to that site, then if the app becomes popular then the site will quickly be overwhelmed.<br />
<br />
The other problem with relying solely on SSL is that it requires trusting the full set of root certificates on the device. This is obviously not a B2G/OWA specific problem but it does seem to be a little worse in this case, '''especially''' in hostile environments when the government has or can easily obtain a root cert. This is why we sign desktop Firefox updates as well as verifying them against a hash downloaded over SSL. Defense in depth.<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408617Apps/Security2012-03-16T20:23:53Z<p>Dchan: /* Definitions */</p>
<hr />
<div>= Boot 2 Gecko App Security Model Discussion =<br />
This page is for capturing information about the B2G/OWA security discussion. <br />
{{note|<b>This is not a design document and should not be considered authoritative at this time</b>}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
* '''Extended Validation (EV) Certificate''' - A SSL certificate that undergoes additional authentication / verification steps before issuance.<br />
** [http://www.cabforum.org/certificates.html Explanation]<br />
** [http://www.cabforum.org/vetting.html Verification process]<br />
* '''Content Security Policy (CSP) - A mechanism by which website administrators can define a policy which restricts what domains a website can load resources from<br />
** [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html Specification]<br />
'''Important reading!''' B2G applications are Open Web Apps, you can read about them here: https://developer.mozilla.org/en-US/apps<br />
<br />
=== Concepts to be given Official Definitions ===<br />
<br />
There is no real easy way to distinguish the following, all of which are iframes (!) in the B2G environment. There is some considerable confusion as a result, especially due to the fact that the required security context and especially the interactions between parent and child iframes are ''different'' depending on the type of iframe.<br />
<br />
Names really therefore need to be given to the following:<br />
<br />
* the root frame (top-level one into which the top gaia HTML is loaded)<br />
* individual gaia apps (sub-iframes, one per app)<br />
* any gaia app that opens up a public-facing (URL-based) iframe in which the contents of a URI are displayed: the browser app is one such<br />
* iframes *within* that iframe - as in "iframes that you normally think of iframes being used for as an ordinary web developer".<br />
<br />
Discussion which raises the issue of confused definitions, helps clarify them:<br />
https://groups.google.com/d/msg/mozilla.dev.b2g/AQYPkIjKxjE/WYy0LPta9cMJ<br />
<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices. (an analogy in debian packaging terms is that the telco sets the initial contents of the /etc/apt/sources.list file)<br />
<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* {{note|Last updated March 14, 2012}}<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] and SELinux for enforcing permissions ===<br />
<br />
The Flask Architecture makes it possible to implement various Access Control systems. SELinux is technically an implementation of Mandatory access control based on Flask Architecture.<br />
<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs in the current implementation is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
Full Discussion on NSA's SE-Linux Mailing List:<br />
http://marc.info/?l=selinux&m=133190422130989&w=2<br />
<br />
Summary points of Discussion on NSA's SE-Linux Mailing List:<br />
<br />
* As B2G is based on Android, it may be worthwhile investigating http://selinuxproject.org/page/SEAndroid<br />
** Apart from anything it will save time on developing the base permission set (to cover the main OS)<br />
** SE-Android is being developed by the NSA ''specifically'' to avoid the need for Android developers to get involved with the "low-level" SE-Linux permissions system.<br />
* ''Stephen Smalley (NSA) has the following recommendation'': See http://www.nsa.gov/research/selinux/related.shtml for some links to work done to apply Flask to various other applications like PostgreSQL, Xorg, and D-BUS.<br />
** Following Stephen's recommendation would allow the creation of very special permissions that are specifically relevant to B2G, for proper enforcement at the Linux Kernel level.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
==== dealing with rogue applications ====<br />
<br />
this section covers how an application may be replaced if discovered to be malicious<br />
<br />
* automatic updates must be enabled (apt-get upgrade)<br />
* people who wish to remain on a "stable" store must have a security-line equivalent to "deb http://security.debian.org/.... "<br />
* rogue applications have a package with a version number "1 higher" than the rogue application's previous package<br />
* the updated package can:<br />
** be a properly bug-fixed version<br />
** contain warnings that the user must explicitly agree to prior to acceptance<br />
** in extreme cases simply replace the files with a blank app that announces "This Application Caused Serious Problems, It Had To Go, Make Sure You Check Your Data N System N Stuff".<br />
<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
==== Kernel permissions manager ====<br />
<br />
{lkcl.15mar12.2223hrs - it's not clear to me what this section refers to: a userspace application that interacts with the user to help them select the level of access that they wish to grant to a particular application, or to the actual kernel-side implementation that enforces the permissions, or a developer "assistance" suite of software which helps the developer to create the permission set that's to be associated with the application when it's installed}<br />
<br />
* separate process that controls access to permissions<br />
* responsible for<br />
*# query permissions, true/false if permissions X is granted<br />
*#* support for prompting user in event permission isn't granted<br />
*# add / remove permissions<br />
*# audit permissions<br />
*# support observers for permission change<br />
* permissions requested are based on "uri signatures"<br />
** to be determined what the signature is: domain, partial url, other?<br />
* permissions representation<br />
** type - usb, web, radio, etc<br />
** uri signature<br />
** value<br />
** source - user, manifest, system<br />
** expiration type - never, time-based, session, other?<br />
** expiration time<br />
** allow message - for UI / prompting user <br />
** deny message<br />
* app obtains permission by querying / asking central process<br />
* OS support required for properly constructing signature, app should not be able to influence this<br />
** there needs to be a unique identifier than an app can't spoof<br />
* permissions requests can be cached<br />
** cache needs to be invalidated on permission change<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
==== The Problem With Using SSL ====<br />
<br />
One problem is that SSL (when used with PKI Certificates for Authentication) is that the solution becomes the problem. When a device may '''only''' download from a site over HTTPS where only those devices which have the appropriate public key may connect to that site, then if the app becomes popular then the site will quickly be overwhelmed.<br />
<br />
The other problem with relying solely on SSL is that it requires trusting the full set of root certificates on the device. This is obviously not a B2G/OWA specific problem but it does seem to be a little worse in this case, '''especially''' in hostile environments when the government has or can easily obtain a root cert. This is why we sign desktop Firefox updates as well as verifying them against a hash downloaded over SSL. Defense in depth.<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/ShowAndTells&diff=408601Apps/ShowAndTells2012-03-16T19:12:49Z<p>Dchan: /* Other */</p>
<hr />
<div>= 2012-02-03 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
<br />
* New "-webapp" mode in Firefox (Dan)<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
<br />
* APK Application stub builder in the cloud (Harald)<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
<br />
* Progress on a new Token Server and overview of AppSync architecture (Bill and Ian)<br />
<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* prototype of in-app payment flow from an app's perspective (Kumar)<br />
* prototype of HTML mockups in Desktop, Tablet, and Mobile modes<br />
* breaking ground on second-stage prototypes running on top of the marketplace server (potch)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
* reference implementation of paywall app -- Ian Bicking<br />
<br />
== Identity ==<br />
<br />
* BrowserID Identity Provider support<br />
<br />
= 2012-02-10 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
<br />
* Webkit-based Soup with harmonized webApps API<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
<br />
* Collections main page for Mobile - http://flee.com/mozilla/<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
* Brian Dils to present Developer UX Project Map<br />
* Jason Smith to present [https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=metrics2&path=%2Fbugzilla%2FWebApps&file=WebApps.wcdf QA Bugzilla Dashboard] for Web Apps<br />
* David Clarke Phase I Test Infrastructure for WebApps [https://wiki.mozilla.org/Apps/QA/Test_Infrastructure]<br />
<br />
= 2012-02-17 =<br />
<br />
<h2> WebRT on desktop (including webapp mode and native app experience) </h2><br />
<ul><br />
<li>Add-on with the new mozApps API, and the ability to install "fake" partner apps.</li><br />
</ul><br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* update on consumer prototype (potch)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-02-24 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* Demo of marketplace being announced on Tuesday (cvan)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
* Some MWC demos?<br />
* Preview of Mozilla Marketplace Apps Partner promo video by Rainer, Spencer & (Havi): http://videos-cdn.mozilla.net/serv/drafts/Mozilla%20Marketplace-RC-SD1%20640.mp4<br />
<br />
= 2012-03-02 =<br />
* Recruiting and stuff<br />
* Let folks know about the [https://jobs.github.com/positions/3418a0c0-64a1-11e1-9f98-03d56429215e HTML5 Apps Partner Engineer] position and check out [http://careers.mozilla.org careers.mozilla.org] to see if you have friends that match apps positions.<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
* [http://paulrouget.com/gaia/ Check out gaia] and think about what's possible! Cool stuff.<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-03-09 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
<br />
* native-looking apps using Firefox as the backend runtime on Windows and Mac<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* [https://developer.mozilla.org/en/Apps/Marketplace_Payments#Price_tiers Price tiers] (fligtar)<br />
* [https://docs.google.com/document/d/1rCGq9txTWE0YQnB6pMUMNns0Adn4B_Oe_hAHKr853U4/edit New schedule proposal] (fligtar)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-03-16 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
** MochiTests Chrome on Desktop (dclarke)<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* App detail page (with basic install flow) - potch<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
== Other ==<br />
* (jsmith) MWC QA Retrospective Presentation<br />
** [https://etherpad.mozilla.org/mwc-qa-retrospective Retrospective Notes]<br />
** [https://docs.google.com/presentation/d/1dh2ki60HWnkS4_mPmWNArzLg99dPkXieJ4DKI5wIxK4/edit Presentation Slides]<br />
* (dchan) B2G / OWA Security Model Discussion<br />
** [[Apps/Security]]</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/ShowAndTells&diff=408590Apps/ShowAndTells2012-03-16T18:55:41Z<p>Dchan: /* Other */</p>
<hr />
<div>= 2012-02-03 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
<br />
* New "-webapp" mode in Firefox (Dan)<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
<br />
* APK Application stub builder in the cloud (Harald)<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
<br />
* Progress on a new Token Server and overview of AppSync architecture (Bill and Ian)<br />
<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* prototype of in-app payment flow from an app's perspective (Kumar)<br />
* prototype of HTML mockups in Desktop, Tablet, and Mobile modes<br />
* breaking ground on second-stage prototypes running on top of the marketplace server (potch)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
* reference implementation of paywall app -- Ian Bicking<br />
<br />
== Identity ==<br />
<br />
* BrowserID Identity Provider support<br />
<br />
= 2012-02-10 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
<br />
* Webkit-based Soup with harmonized webApps API<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
<br />
* Collections main page for Mobile - http://flee.com/mozilla/<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
* Brian Dils to present Developer UX Project Map<br />
* Jason Smith to present [https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=metrics2&path=%2Fbugzilla%2FWebApps&file=WebApps.wcdf QA Bugzilla Dashboard] for Web Apps<br />
* David Clarke Phase I Test Infrastructure for WebApps [https://wiki.mozilla.org/Apps/QA/Test_Infrastructure]<br />
<br />
= 2012-02-17 =<br />
<br />
<h2> WebRT on desktop (including webapp mode and native app experience) </h2><br />
<ul><br />
<li>Add-on with the new mozApps API, and the ability to install "fake" partner apps.</li><br />
</ul><br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* update on consumer prototype (potch)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-02-24 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* Demo of marketplace being announced on Tuesday (cvan)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
* Some MWC demos?<br />
* Preview of Mozilla Marketplace Apps Partner promo video by Rainer, Spencer & (Havi): http://videos-cdn.mozilla.net/serv/drafts/Mozilla%20Marketplace-RC-SD1%20640.mp4<br />
<br />
= 2012-03-02 =<br />
* Recruiting and stuff<br />
* Let folks know about the [https://jobs.github.com/positions/3418a0c0-64a1-11e1-9f98-03d56429215e HTML5 Apps Partner Engineer] position and check out [http://careers.mozilla.org careers.mozilla.org] to see if you have friends that match apps positions.<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
* [http://paulrouget.com/gaia/ Check out gaia] and think about what's possible! Cool stuff.<br />
<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-03-09 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
<br />
* native-looking apps using Firefox as the backend runtime on Windows and Mac<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
* [https://developer.mozilla.org/en/Apps/Marketplace_Payments#Price_tiers Price tiers] (fligtar)<br />
* [https://docs.google.com/document/d/1rCGq9txTWE0YQnB6pMUMNns0Adn4B_Oe_hAHKr853U4/edit New schedule proposal] (fligtar)<br />
<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
<br />
= 2012-03-16 =<br />
<br />
== WebRT on desktop (including webapp mode and native app experience) ==<br />
** MochiTests Chrome on Desktop (dclarke)<br />
<br />
== WebRT on Android (including webapp mode and native app experience) ==<br />
== AppSync (for WebRTs and HTML5) ==<br />
== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==<br />
== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==<br />
== Other ==<br />
* (jsmith) MWC QA Retrospective Presentation<br />
** [https://etherpad.mozilla.org/mwc-qa-retrospective Retrospective Notes]<br />
** [https://docs.google.com/presentation/d/1dh2ki60HWnkS4_mPmWNArzLg99dPkXieJ4DKI5wIxK4/edit Presentation Slides]<br />
* (dchan) B2G / OWA Security Model<br />
** [[Apps/Security]]</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408339Apps/Security2012-03-15T23:52:30Z<p>Dchan: /* Centralized permissions manager */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
This page is for capturing information about the B2G/OWA security discussion. <br />
{{note|<b>This is not a design document and should not be considered authoritative at this time</b>}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
<br />
=== Concepts to be given Official Definitions ===<br />
<br />
There is no real easy way to distinguish the following, all of which are iframes (!) in the B2G environment. There is some considerable confusion as a result, especially due to the fact that the required security context and especially the interactions between parent and child iframes are ''different'' depending on the type of iframe.<br />
<br />
Names really therefore need to be given to the following:<br />
<br />
* the root frame (top-level one into which the top gaia HTML is loaded)<br />
* individual gaia apps (sub-iframes, one per app)<br />
* any gaia app that opens up a public-facing (URL-based) iframe in which the contents of a URI are displayed: the browser app is one such<br />
* iframes *within* that iframe - as in "iframes that you normally think of iframes being used for as an ordinary web developer".<br />
<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* {{note|Last updated March 14, 2012}}<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
==== Kernel permissions manager ====<br />
<br />
{lkcl.15mar12.2223hrs - it's not clear to me what this section refers to: a userspace application that interacts with the user to help them select the level of access that they wish to grant to a particular application, or to the actual kernel-side implementation that enforces the permissions, or a developer "assistance" suite of software which helps the developer to create the permission set that's to be associated with the application when it's installed}<br />
<br />
* separate process that controls access to permissions<br />
* responsible for<br />
*# query permissions, true/false if permissions X is granted<br />
*#* support for prompting user in event permission isn't granted<br />
*# add / remove permissions<br />
*# audit permissions<br />
*# support observers for permission change<br />
* permissions requested are based on "uri signatures"<br />
** to be determined what the signature is: domain, partial url, other?<br />
* permissions representation<br />
** type - usb, web, radio, etc<br />
** uri signature<br />
** value<br />
** source - user, manifest, system<br />
** expiration type - never, time-based, session, other?<br />
** expiration time<br />
** allow message - for UI / prompting user <br />
** deny message<br />
* app obtains permission by querying / asking central process<br />
* OS support required for properly constructing signature, app should not be able to influence this<br />
** there needs to be a unique identifier than an app can't spoof<br />
* permissions requests can be cached<br />
** cache needs to be invalidated on permission change<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408293Apps/Security2012-03-15T21:04:41Z<p>Dchan: /* Centralized permissions manager */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* {{note|Last updated March 14, 2012}}<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
==== Centralized permissions manager ====<br />
* separate process that controls access to permissions<br />
* responsible for<br />
*# query permissions, true/false if permissions X is granted<br />
*#* support for prompting user in event permission isn't granted<br />
*# add / remove permissions<br />
*# audit permissions<br />
*# support observers for permission change<br />
* permissions requested are based on "uri signatures"<br />
** to be determined what the signature is: domain, partial url, other?<br />
* permissions representation<br />
** type - usb, web, radio, etc<br />
** uri signature<br />
** value<br />
** source - user, manifest, system<br />
** expiration type - never, time-based, session, other?<br />
** expiration time<br />
** allow message - for UI / prompting user <br />
** deny message<br />
* app obtains permission by querying / asking central process<br />
* OS support required for properly constructing signature, app should not be able to influence this<br />
** there needs to be a unique identifier than an app can't spoof<br />
* permissions requests can be cached<br />
** cache needs to be invalidated on permission change<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408288Apps/Security2012-03-15T20:53:16Z<p>Dchan: /* Proposals */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* {{note|Last updated March 14, 2012}}<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
==== Centralized permissions manager ====<br />
*<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=408270Apps/Security2012-03-15T20:26:47Z<p>Dchan: /* Boot 2 Gecko / OpenWebApps Security Model */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)<br />
# Apps cannot request permission to do something that is not listed in the manifest<br />
<br />
discussion links:<br />
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE<br />
<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Types of Runnables ===<br />
<br />
There are 4 (or more) types of possible runnables so far identified on B2G:<br />
<br />
* 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.<br />
* 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)<br />
* 2) Installed non-local Web apps (including sites).<br />
* 3) Non-installed Web apps (including sites).<br />
* 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system<br />
<br />
(It seems all type 1 runnables can be implements as type 2 or 0. Maybe<br />
we needn't treat them as a seperate type)<br />
<br />
For type 0 & 1, a deployment mechanism like apt/yum works fine (and<br />
seems required for type 0). But for type 2 & 3, such mechanism may not<br />
cover. I'm afraid that many apps will be implemented as type 2 or 3<br />
for smooth of (re)deployment (and this is a huge advantage for web<br />
apps to native ones).<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires the following extremely difficult tasks to be carried out:<br />
*# compromise the site hosting the app<br />
*# compromise the keys (developer *and* FTP master) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
* should the JS "eval" function have a permission added to it?<br />
* bypassing the official package system speeds up app development<br />
** at the risk of destabilising a system!<br />
** should still be allowed though (with caveat that warranty just got voided)<br />
** concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps<br />
* self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85<br />
** The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407945Apps/Security2012-03-15T00:12:11Z<p>Dchan: /* Trusted store with permissions delegation */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
{{note|Last updated March 14, 2012}}<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** {{note|This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).}}<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones<br />
** However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
** an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).<br />
** in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)<br />
* use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|There are license issue that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407939Apps/Security2012-03-14T23:57:58Z<p>Dchan: /* Boot 2 Gecko / OpenWebApps Security Model */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Definitions ==<br />
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content<br />
* '''Native App''' - A WebApp consisting solely of static content and run on a B2G capable device<br />
* '''Store''' - A marketplace where a user may download/purchase WebApps for their device<br />
* above definition are up for discussion<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|There are license issue that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407937Apps/Security2012-03-14T23:52:37Z<p>Dchan: /* Debian Keyring (Package Management) for distribution of apps */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
==== debconf shim for B2G native apps ====<br />
# a user goes to a store (GUI front-end TBD)<br />
# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)<br />
# they go "i wanna app wiv a cherry on top"<br />
# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".<br />
# the GUI uses the dpkg / debconf communication system to inform them of progress<br />
# the GUI then walks them through the security questions (which is all part of debconf)<br />
* we would distribute a debconf frontend app for B2G<br />
* B2G app communicates with dpkg/debconf through something like a unix pipe<br />
* the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed<br />
* B2G app only receives progress updates<br />
* it may be possible to leverage the existing Debian package infrastructure<br />
** {{note|There are license issue that need to be resolved}}<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407902Apps/Security2012-03-14T22:41:12Z<p>Dchan: /* Other (topics that don't fall into above proposals) */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* Last updated March 14, 2012<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
*** complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407899Apps/Security2012-03-14T22:37:18Z<p>Dchan: /* Open questions */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?<br />
# What would be signed?<br />
#* CSS<br />
#* scripts<br />
#* content<br />
#* other</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407895Apps/Security2012-03-14T22:35:59Z<p>Dchan: /* Boot 2 Gecko / OpenWebApps Security Model */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
* Track the status of [[B2G_App_Security_Model]]<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407893Apps/Security2012-03-14T22:33:28Z<p>Dchan: /* App instance / version */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* Last updated March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407892Apps/Security2012-03-14T22:33:01Z<p>Dchan: /* Debian Keyring (Package Management) for distribution of apps */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Last updated March 14, 2012<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
* To compromise an app with proper code signing requires<br />
*# compromise the site hosting the app<br />
*# compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)<br />
*# compromise or trigger the update mechanism for the app<br />
*# wait for updates to trickle out<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407890Apps/Security2012-03-14T22:27:25Z<p>Dchan: /* Proposals */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== App instance / version ===<br />
* March 14, 2012<br />
* Possible definitions of what an app instance / version is<br />
*# a static bundle of code authenticated by manifest + signature (or equivalent)<br />
*# a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)<br />
*# an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants<br />
*# unauthenticated code loaded over any channel, from any origin<br />
* loosely ordered from best to worst (descending) security wise<br />
* 1) and 2) could work with additional security mitigations<br />
* attacker can use option 2) as a proxy for malicious content<br />
* attacker can use option 2) as proxy to paid app (buy once, share with world)<br />
** mitigation for this may be responsibility of app developer<br />
* CSP can secure 1) and 2) to an extent<br />
** define baseline CSP policy that apps have to adopt<br />
* See [https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html Intro to AIR security]<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=407886Apps/Security2012-03-14T22:17:32Z<p>Dchan: /* Boot 2 Gecko / OpenWebApps Security Model */</p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
== Bugs ==<br />
* {{bug|707625}} - WebAPI permissions manager<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=406730Apps/Security2012-03-13T00:04:08Z<p>Dchan: </p>
<hr />
<div>= Boot 2 Gecko / OpenWebApps Security Model =<br />
{{note|This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time}}<br />
== Requirements == <br />
=== Distribution / management of WebApps ===<br />
# It should not be trivially easy for a rogue application to be listed on a marketplace / store<br />
# A store may revoke a bad / malicious WebApp<br />
# A telco can decide which stores to implicitly trust on their devices<br />
=== Management / granting of API permissions to WebApps ===<br />
# User should be able to view / control / modify permissions granted to WebApps<br />
# WebApps should fail gracefully if not all permissions granted<br />
# User should have control over APIs with privacy implications<br />
=== Enforcement of permissions on device ===<br />
# Permissions should be enforced regardless of version of B2G installed<br />
<br />
== Proposals ==<br />
=== Trusted store with permissions delegation ===<br />
* Mozilla (telco store) acts as an authority for permissions requests<br />
* WebApps request permissions in manifest<br />
* Each store contains a set of permissions they can grant<br />
* The "root" store may grant any permissions<br />
* A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions<br />
** ACME is a root store<br />
** ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts<br />
** Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions<br />
** Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted<br />
* Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant<br />
** WidgetIncApp is listed on ACME store<br />
** WidgetIncApp requests Hammer, Nail permissions<br />
** ACME store has been granted Hammer, Screw permissions by telco<br />
** WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions<br />
** There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer<br />
** "blessed" apps must always be served from the store with access to source code<br />
* Selfhosting of WebApp<br />
** A WebApp can be self-hosted and query a trusted store on install<br />
** The WebApp will be granted permissions based on what the trusted store would have granted the WebApp<br />
*** WidgetInc wants to host WidgetIncApp from widget.lol<br />
*** WidgetInc has already uploaded WidgetIncApp to ACME Store<br />
*** User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store<br />
*** Runtime queries ACME Store to see what permissions should be given to WidgetIncApp<br />
<br />
=== [http://www.cs.utah.edu/flux/fluke/html/flask.html FLASK] for enforcing permissions ===<br />
* Tested architecture that is used SELinux<br />
* Follows a mandatory access control model where no permissions are granted by default<br />
* There is no inheritance of ACLs / permissions<br />
** If a WebApp were to change / do something new, it wouldn't have its old permissions<br />
* "what you can do depends on who you were, where you are *AND* what you're executing."<br />
* Adopting for use in B2G means writing an interface that mediates API / systemcalls<br />
** Suggestion was a JSONRPC service<br />
* API access would be enforced across security contexts<br />
** e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.<br />
<br />
=== Debian Keyring (Package Management) for distribution of apps ===<br />
* Items in () denote the equivalent in WebApp world<br />
* infrastructure already exists<br />
* Code is cryptographically signed by multiple parties<br />
** Package (WebApp) maintainer (author / company)<br />
** Package is signed by FTP masters (marketplace / store?)<br />
* Signed packages / manifests are separate from binaries (HTML content)<br />
** We need a way to verify that the WebApp content has not changed<br />
* The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)<br />
* A user may choose to add more sources (stores)<br />
* A user must add the source's keyring (store's public key?) to disable warning about untrusted source<br />
<br />
=== Permissions manager ===<br />
* User can deny permissions at install time<br />
* User can always go to manager to see what permissions an app has been granted<br />
* User can modify permissions through the manager<br />
* Certain APIs are defined as "sensitive"<br />
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi<br />
* Levels of access for capabilities<br />
** Allow<br />
** Prompt (default to remember)<br />
** Prompt (default to not remember)<br />
** Deny<br />
*** There were concerns that the levels should only be Allow/Deny<br />
* Contractual enforcement of permissions<br />
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs<br />
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions<br />
* WebApps may be granted default permissions<br />
** e.g. access to storage, access to change context menu<br />
* capabilities may be restricted based on technical restrictions of the site<br />
** e.g. strict-transport security, EV-certificate<br />
<br />
=== Other (topics that don't fall into above proposals) ===<br />
* SSL should be used for content delivery<br />
** can provide authentication for client-store communication<br />
** provides end-to-end security<br />
** does not address concerns of a malicious app<br />
* W^X / NX for WebApps<br />
<br />
== Open questions ==<br />
# What happens when a WebApp is revoked?<br />
#* removed from store?<br />
#* removed from user device?<br />
#* refund?<br />
# What is the identifier used when a WebApp is revoked?<br />
#* origin (scheme + host + port)<br />
#* certificate / hash embed inside WebApp manifest<br />
# Should eval() and similar functions be considered sensitive APIs / restricted?<br />
#* Adobe AIR restricts eval() in the application sandbox [http://help.adobe.com/en_US/air/html/security/WS485a42d56cd1964150c3d3a8124ef1cbd62-7ffe.html (docs)]<br />
# Should self-signed certificates be allowed?</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-03-06&diff=404552Services/Meetings/2012-03-062012-03-06T17:20:06Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
== BrowserID ==<br />
* BrowserID software push today<br />
* BrowserID goes multi-DC tomorrow<br />
** YAY<br />
<br />
== Staff ==<br />
* Offer out to Bob (Ops Eng)<br />
** Nothing signed, but has verbally accepted.<br />
* Reminder for some: Interviewing Ops Eng candidate "Brent" on Thursday<br />
<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller) ===<br />
* metlog-py 0.8.1 released (significant config and app integration related improvements)<br />
* work done on CEF back end for logstash<br />
* first phase of mozsvc metlog integration completed<br />
* nearly done integrating metlog into latest server-syncstorage<br />
* gathered useful requirements re: specific data points to gather from existing production services<br />
<br />
=== SyncStorage (rfkelly) ===<br />
<br />
Done:<br />
* dealing with backlog of bugs that we decided to fix in 2.0 only (e.g. collections table re-org)<br />
* tried building some rpms<br />
<br />
Next:<br />
* out for rest of this week (travelling to PyCon, attending PyCon)<br />
* working from Mountain View next week. Yay Pacific Time!<br />
* work on some loadtesting etc<br />
<br />
=== Queuey (bbangert) ===<br />
<br />
* Did basic load testing on Cassandra on ghetto cluster<br />
* Ghetto cluster able to handle Socorro peak load, and then some<br />
* Writing docs and docs and docs<br />
<br />
=== Token Server (tarek/alexis) ===<br />
Last week <br />
<br />
* sql backend ready (with sharding)<br />
* still powerhose + tokenserver crypto<br />
<br />
This Week<br />
<br />
* Tarek is at Pycon<br />
* MOAR coffee<br />
* benching of the whole stack<br />
* finishing crypto bits<br />
* documentation on the tokenserver (internal doc)<br />
* Ask for code review on the c++ part to some c++ experts even if this is not finished yet, would need to have some advices from c++ folks) (gps, etc..)<br />
* change the pyvep dep to browserid (after the changed by rfk)<br />
* Take some time to review general services documentation and add howto start, etc.<br />
<br />
=== Cornice (tarek/alexis) ===<br />
Nothing new.<br />
<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Major 2.0 + BID refactoring in progress in GitHub.<br />
** Outstanding patches for rnewman now >500K, 14kloc :D<br />
** Implemented generic client for Storage Service 2.0<br />
** Implemented standalone Sync JS client<br />
** Refactoring existing code to make it suck less<br />
** Backporting patches to s-c when it makes sense, is easy<br />
<br />
=== Android Sync (rnewman) ===<br />
== Notifications ==<br />
=== Bipostal (jrconlin) ===<br />
* QA setup<br />
* Documentation<br />
* Waiting for Mr. Good API<br />
<br />
=== Client/Server (jbalogh) ===<br />
* Went to Urban Airship, learned all their secrets<br />
* Collaborating with a community contributor on notifications UX: http://jsbin.com/akukug/2/edit#preview<br />
* Working on notifications as an add-on<br />
<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* {{Bug|731024}} Unsupported record types causes Android Sync to reorder folders containing livemarks/queries/separators on desktop. QA likely to block beta on this desktop UX issue. Which depends on;<br />
* {{Bug|708149}} Handling of unsupported bookmark records.<br />
* Caught up on NAS verifications<br />
* QA waiting as anxiously as devs for content type work from Fennec team. <br />
* No desktop client train last week<br />
<br />
== Sync Server (jbonacci) ==<br />
* Working with rfkelly on initial QA/Dev testing of Sync 2.0 against various flavors of Linux<br />
** http://www.rfk.id.au/static/scratch/moz-services-docs/storage/apis-2.0.html<br />
** Bug 727761 - [meta] implement sync2.0 on top of pyramid/cornice/mozsvc<br />
** Bug 731511 - Make it easy to run functional tests against a remote server<br />
*** and a bunch of other tickets<br />
<br />
* Working with jrconlin on some initial QA/Dev testing of BiPostal on qa1 VM<br />
<br />
* QA test planning in in progress for the following projects:<br />
** MetLog<br />
** Token Server<br />
** Sync 2.0/Token Server combo<br />
<br />
== BrowserID (jbonacci) ==<br />
* Train 22: Bug 732142 - QA and deploy BrowserID train-2012.03.01 to production<br />
* HotFix 1 for Issue 1235<br />
* HotFix 2 for Issues 1258 and 1259<br />
<br />
* Prod deployment for HotFix2, above:<br />
** Bug 733287 - deploy hotfix browserid-server 2012.02.16-3 to production sweb<br />
** Bug 733288 - bid dbwriters: monitor /wsapi/have_email<br />
<br />
* Continue working with OPs on PHX1 build-out for BID<br />
** Bug 695940 - BrowserID production tracking bug<br />
** Bug 726614 - browserid: multi-datacenter tracking bug<br />
<br />
== BrowserID automation (jrgm) ==<br />
== TPS (jgriffin) ==<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security (dchan) =<br />
* No updates for this week<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
== Notes and actions ==<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-02-28&diff=401838Services/Meetings/2012-02-282012-02-28T17:26:24Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller) ===<br />
* Refactored generally useful mozsvc pieces into metlog-py<br />
* Added extensibility to Metlog client<br />
* Started poking at BrowserId-Sync integration<br />
* Finalizing logstash CEF output module<br />
* new metlog-py release imminent<br />
<br />
=== SyncStorage (rfkelly) ===<br />
=== Queuey (bbangert) ===<br />
<br />
* Finished API redesign of queuey<br />
* Working on Moar docs<br />
* Add Metlog?<br />
* Start on load testing and load testing scripts<br />
<br />
=== Token Server (tarek) ===<br />
<br />
Last week <br />
<br />
* polished and prepared circus for a release [circus]<br />
* added a funkload bench [token server]<br />
* plugged circus into powerhose [powerhose]<br />
* plugged everything in token server so running it runs n circus-ed processes<br />
* Refactored PyVEP to be easily extensible regarding c++; changed the way tests are conducted [PyVEP]<br />
* implemented a secrets file manager [token]<br />
* moved the certificate handling into a separate certificates module [PyVEP]<br />
* First version of the pure python powerhose worker for crypto [tokenserver]<br />
* started to discuss the sql switch [token server]<br />
<br />
This week<br />
<br />
* finish the sql backend implementation [token server]<br />
* finish the pure python powerhose worker for crypto [token server]<br />
* plug the c++ worker [token server]<br />
<br />
=== Cornice (tarek) ===<br />
<br />
Last week <br />
<br />
* allow support of custom status code for errors <br />
<br />
This week<br />
<br />
* nothing planned for now<br />
<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Landed HTTP MAC API support in s-c<br />
* Token server client review underway<br />
* Identity and auth refactor feedback underway (250K patch for rnewman, muhahaha)<br />
* Protocol 2.0 patch ongoing.<br />
<br />
=== Android Sync (rnewman) ===<br />
== Notifications ==<br />
=== Bipostal (jrconlin) ===<br />
* Fun with Entropy (you down with me?)<br />
* break user & email into separate fields <br />
* continue test buildup<br />
<br />
=== Client/Server (jbalogh) ===<br />
* @ Urban Airship<br />
<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* Sign off on a small desktop train last week<br />
* tested around Android Sync bookmarks improvements<br />
** nightly user found {{bug|731024}}<br />
* blogging about sync QA to commence this week (I've never been a good writer, so I'm just a leettle ascared to start)<br />
<br />
== Sync Server (jbonacci) ==<br />
* Testing continues as needed for any Sync Server deployments and Change/Maintenance Windows.<br />
* Got a local install of Sync 2.0 up and running on Ubuntu 11 with help from rfkelly.<br />
** Will be trying to generalize the installation so we can use on OPs VMs like qa1<br />
** Will continue working with rfkelly to get local/VM install pointing to his Sync 2.0 API server: http://sync1.web.mtv1.dev.svc.mozilla.com/<br />
* QA test planning in in progress for the following projects:<br />
** MetLog<br />
** BiPostal<br />
** Token Server<br />
** Sync 2.0/Token Server combo<br />
<br />
== BrowserID (jbonacci) ==<br />
* Finishing up on Train 21<br />
** Bug 727995 - QA and deploy BrowserID train-2012.02.16 to production<br />
** HotFix: Bug 729561 - BrowserID: Deploy hotfix to production at 1pm pacific<br />
* Getting Zak up-to-speed on some basic black box testing<br />
* We have another Test Day planned for Friday, March 9<br />
** Themes: UI, primary support, localization<br />
* QA test planning for PHX1 build-out this week or next<br />
<br />
== BrowserID automation (jrgm) ==<br />
== TPS (jgriffin) ==<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security =<br />
* Token Server threat modeling session 2/29 12PM Pacific<br />
** MV 2JK<br />
** SF0 7B<br />
<br />
* Token Server testing to start this week<br />
* Rescheduling of queuey review<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
== Notes and actions ==<br />
* Tarek's Show and Tell<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-02-28&diff=401828Services/Meetings/2012-02-282012-02-28T17:23:18Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller) ===<br />
* Refactored generally useful mozsvc pieces into metlog-py<br />
* Added extensibility to Metlog client<br />
* Started poking at BrowserId-Sync integration<br />
* Finalizing logstash CEF output module<br />
* new metlog-py release imminent<br />
<br />
=== SyncStorage (rfkelly) ===<br />
=== Queuey (bbangert) ===<br />
<br />
* Finished API redesign of queuey<br />
* Working on Moar docs<br />
* Add Metlog?<br />
* Start on load testing and load testing scripts<br />
<br />
=== Token Server (tarek) ===<br />
<br />
Last week <br />
<br />
* polished and prepared circus for a release [circus]<br />
* added a funkload bench [token server]<br />
* plugged circus into powerhose [powerhose]<br />
* plugged everything in token server so running it runs n circus-ed processes<br />
* Refactored PyVEP to be easily extensible regarding c++; changed the way tests are conducted [PyVEP]<br />
* implemented a secrets file manager [token]<br />
* moved the certificate handling into a separate certificates module [PyVEP]<br />
* First version of the pure python powerhose worker for crypto [tokenserver]<br />
* started to discuss the sql switch [token server]<br />
<br />
This week<br />
<br />
* finish the sql backend implementation [token server]<br />
* finish the pure python powerhose worker for crypto [token server]<br />
* plug the c++ worker [token server]<br />
<br />
=== Cornice (tarek) ===<br />
<br />
Last week <br />
<br />
* allow support of custom status code for errors <br />
<br />
This week<br />
<br />
* nothing planned for now<br />
<br />
=== Sauropod (rtilder) ===<br />
=== Big Lebowski (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Landed HTTP MAC API support in s-c<br />
* Token server client review underway<br />
* Identity and auth refactor feedback underway (250K patch for rnewman, muhahaha)<br />
* Protocol 2.0 patch ongoing.<br />
<br />
=== Android Sync (rnewman) ===<br />
== Notifications ==<br />
=== Bipostal (jrconlin) ===<br />
* Fun with Entropy (you down with me?)<br />
* break user & email into separate fields <br />
* continue test buildup<br />
<br />
=== Client/Server (jbalogh) ===<br />
* @ Urban Airship<br />
<br />
== Beta Channel ==<br />
=== Program Launch (mconnor) ===<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* Sign off on a small desktop train last week<br />
* tested around Android Sync bookmarks improvements<br />
** nightly user found {{bug|731024}}<br />
* blogging about sync QA to commence this week (I've never been a good writer, so I'm just a leettle ascared to start)<br />
<br />
== Sync Server (jbonacci) ==<br />
* Testing continues as needed for any Sync Server deployments and Change/Maintenance Windows.<br />
* Got a local install of Sync 2.0 up and running on Ubuntu 11 with help from rfkelly.<br />
** Will be trying to generalize the installation so we can use on OPs VMs like qa1<br />
** Will continue working with rfkelly to get local/VM install pointing to his Sync 2.0 API server: http://sync1.web.mtv1.dev.svc.mozilla.com/<br />
* QA test planning in in progress for the following projects:<br />
** MetLog<br />
** BiPostal<br />
** Token Server<br />
** Sync 2.0/Token Server combo<br />
<br />
== BrowserID (jbonacci) ==<br />
* Finishing up on Train 21<br />
** Bug 727995 - QA and deploy BrowserID train-2012.02.16 to production<br />
** HotFix: Bug 729561 - BrowserID: Deploy hotfix to production at 1pm pacific<br />
* Getting Zak up-to-speed on some basic black box testing<br />
* We have another Test Day planned for Friday, March 9<br />
** Themes: UI, primary support, localization<br />
* QA test planning for PHX1 build-out this week or next<br />
<br />
== BrowserID automation (jrgm) ==<br />
== TPS (jgriffin) ==<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security =<br />
* Token Server threat modeling session 2/29 12PM Pacific<br />
** MV 2JK<br />
** SF0 7B<br />
<br />
* Token Server testing to start this week<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
== Notes and actions ==<br />
* Tarek's Show and Tell<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-02-28&diff=401822Services/Meetings/2012-02-282012-02-28T17:21:53Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller) ===<br />
* Refactored generally useful mozsvc pieces into metlog-py<br />
* Added extensibility to Metlog client<br />
* Started poking at BrowserId-Sync integration<br />
* Finalizing logstash CEF output module<br />
* new metlog-py release imminent<br />
<br />
=== SyncStorage (rfkelly) ===<br />
=== Queuey (bbangert) ===<br />
<br />
* Finished API redesign of queuey<br />
* Working on Moar docs<br />
* Add Metlog?<br />
* Start on load testing and load testing scripts<br />
<br />
=== Token Server (tarek) ===<br />
<br />
Last week <br />
<br />
* polished and prepared circus for a release [circus]<br />
* added a funkload bench [token server]<br />
* plugged circus into powerhose [powerhose]<br />
* plugged everything in token server so running it runs n circus-ed processes<br />
* Refactored PyVEP to be easily extensible regarding c++; changed the way tests are conducted [PyVEP]<br />
* implemented a secrets file manager [token]<br />
* moved the certificate handling into a separate certificates module [PyVEP]<br />
* First version of the pure python powerhose worker for crypto [tokenserver]<br />
* started to discuss the sql switch [token server]<br />
<br />
This week<br />
<br />
* finish the sql backend implementation [token server]<br />
* finish the pure python powerhose worker for crypto [token server]<br />
* plug the c++ worker [token server]<br />
<br />
=== Cornice (tarek) ===<br />
<br />
Last week <br />
<br />
* allow support of custom status code for errors <br />
<br />
This week<br />
<br />
* nothing planned for now<br />
<br />
=== Sauropod (rtilder) ===<br />
=== Big Lebowski (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Landed HTTP MAC API support in s-c<br />
* Token server client review underway<br />
* Identity and auth refactor feedback underway (250K patch for rnewman, muhahaha)<br />
* Protocol 2.0 patch ongoing.<br />
<br />
=== Android Sync (rnewman) ===<br />
== Notifications ==<br />
=== Bipostal (jrconlin) ===<br />
* Fun with Entropy (you down with me?)<br />
* break user & email into separate fields <br />
* continue test buildup<br />
<br />
=== Client/Server (jbalogh) ===<br />
* @ Urban Airship<br />
<br />
== Beta Channel ==<br />
=== Program Launch (mconnor) ===<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* Sign off on a small desktop train last week<br />
* tested around Android Sync bookmarks improvements<br />
** nightly user found {{bug|731024}}<br />
* blogging about sync QA to commence this week (I've never been a good writer, so I'm just a leettle ascared to start)<br />
<br />
== Sync Server (jbonacci) ==<br />
* Testing continues as needed for any Sync Server deployments and Change/Maintenance Windows.<br />
* Got a local install of Sync 2.0 up and running on Ubuntu 11 with help from rfkelly.<br />
** Will be trying to generalize the installation so we can use on OPs VMs like qa1<br />
** Will continue working with rfkelly to get local/VM install pointing to his Sync 2.0 API server: http://sync1.web.mtv1.dev.svc.mozilla.com/<br />
* QA test planning in in progress for the following projects:<br />
** MetLog<br />
** BiPostal<br />
** Token Server<br />
** Sync 2.0/Token Server combo<br />
<br />
== BrowserID (jbonacci) ==<br />
* Finishing up on Train 21<br />
** Bug 727995 - QA and deploy BrowserID train-2012.02.16 to production<br />
** HotFix: Bug 729561 - BrowserID: Deploy hotfix to production at 1pm pacific<br />
* Getting Zak up-to-speed on some basic black box testing<br />
* We have another Test Day planned for Friday, March 9<br />
** Themes: UI, primary support, localization<br />
* QA test planning for PHX1 build-out this week or next<br />
<br />
== BrowserID automation (jrgm) ==<br />
== TPS (jgriffin) ==<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Beyond ===<br />
== Identity ==<br />
= Security =<br />
* Token Server threat modeling session 2/29<br />
** MV 2JK<br />
** SF0 7B<br />
<br />
* Token Server testing to start this week<br />
<br />
= Marketing =<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
== Notes and actions ==<br />
* Tarek's Show and Tell<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-02-21&diff=399678Services/Meetings/2012-02-212012-02-21T17:28:21Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, Sick Bay (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
= Engineering =<br />
== Sagrada ==<br />
=== Metrics (rmiller) ===<br />
* Further logstash output work completed<br />
* Add'l development on mozsvc / metlog integration<br />
* Design / planning re: metlog-py roadmap<br />
* Testing and packaging for HDFS back end components<br />
* New RPMs delivered for next round of load testing<br />
<br />
=== SyncStorage (rfkelly) ===<br />
=== Queuey (bbangert) ===<br />
=== Token Server (tarek) ===<br />
<br />
Last Week<br />
<br />
* Implemented the snode/sreg part of tokenserver<br />
* plugged it with pyvep via repoze.who.plugins.vepauth<br />
* deployed http://token{1,2}.reg.mtv1.dev.svc.mozilla.com/<br />
* powerhose *master* is now included in tokenserver (off by default)<br />
* worked on wrapping up circus - license issues pending<br />
<br />
This week<br />
<br />
* create the powerhose c++ worker for the tokenserver (to do JWT verifications) <br />
* finish the implementation of the certificate reloading <br />
* finish the implementation of the secret key loading + need investigation in PyVEP <br />
* deploy second box <br />
* test the ldap code against a real ldap infrastructure <br />
* add cache support for the tokenserver<br />
<br />
=== Cornice (tarek) ===<br />
=== Sauropod (rtilder) ===<br />
=== Big Lebowski (rtilder) ===<br />
== Sync ==<br />
=== Firefox Sync (gps) ===<br />
* Add-on sync bug fix {{bug|712542}}.<br />
* Sync 2.0 branch work in Git<br />
<br />
=== Android Sync (rnewman) ===<br />
== Notifications ==<br />
=== Bipostal (jrconlin) ===<br />
* Added draft MAC auth code to notifications (Need to expand python and js to full libraries and add third party testing harnesses)<br />
* Bunch of Notifications crossover work.<br />
* Activated "disable" feature to addresses in bipostal.<br />
<br />
* Meeting with badida today to discuss integration work for Bipostal as BID plugin.<br />
<br />
=== Client/Server (jbalogh) ===<br />
* working on notifications as a restartless add-on<br />
* starting the battle with the Data Safety Council<br />
<br />
== Beta Channel ==<br />
=== Program Launch (mconnor) ===<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* testing Android code drop .5<br />
* working on automation in sikuli<br />
* preparing videos for community engagement.<br />
<br />
== Sync Server (jbonacci) ==<br />
* Testing continues as needed for any Sync Server deployments and Change/Maintenance Windows.<br />
* Test scripts are in progress for running curl against rfkelly's Sync 2.0 setup<br />
** http://sync1.web.mtv1.dev.svc.mozilla.com/<br />
** Need to get some help from Ryan/Toby on account creation and DB for a single test account/user<br />
* QA test planning in in progress for the following projects:<br />
** MetLog<br />
** BiPostal<br />
** Sync 2.0 with Token Server<br />
<br />
== BrowserID (jbonacci) ==<br />
* Actively working on Train 21 in Stage:<br />
** Bug 727995 - QA and deploy BrowserID train-2012.02.16 to production<br />
** Main focus on this train, again, is support for primaries, UX, localization<br />
<br />
== BrowserID automation (jrgm) ==<br />
* working on basic selenium tests for browserid sign_in dialog<br />
* QA and deploy BrowserID train-2012.02.16 to production<br />
<br />
== TPS (jgriffin) ==<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Beyond ===<br />
<br />
== Identity ==<br />
<br />
= Security =<br />
* Queuey threat modeling<br />
** Location: "SFO-7B" <sfo-7b@mozilla.com>; "Warp Core" <warpcore@mozilla.com><br />
** Date: Feb 24, 2012 from 10:00 AM to 11:00 AM GMT -08:00 US/Canada Pacific<br />
<br />
* Metlog threat modeling<br />
** Location: "4M - Michael Bolton" <4m@mozilla.com> (4M - Michael Bolton)<br />
** Date: Feb 27, 2012 from 1:00 PM to 2:00 PM GMT -08:00 US/Canada Pacific<br />
<br />
TODO:<br />
send livecycle documentation to services team for security checklist<br />
<br />
= Marketing =<br />
<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
<br />
== Notes and actions ==<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=394831Apps/Security2012-02-07T17:02:19Z<p>Dchan: /* Dataflow */</p>
<hr />
<div>== API permissions ==<br />
=== Dataflow ===<br />
[File:WebApp_DFD.png]<br />
<br />
=== What are we trying to solve? ===<br />
We want to define API permissions taking into account the follow threats<br />
# How to protect user from malicious app<br />
#* An app should not be able to perform more than it's manifest specifies<br />
# How to protect user from MITM attack<br />
#* This may result in a malicious app scenario<br />
#* We don't want to leak a user's personal information (contacts, messages, voicemail, etc)<br />
<br />
=== Proposed solution ===<br />
* APIs should have separate permissions for read and write/modify.<br />
** e.g. an app that only needs to check call state does not need access to perform calls<br />
* APIs that need internet access should define what domains they need to talk to<br />
* Manifest should be served over SSL<br />
** doesn't protect against a compromised cert<br />
** cert pinning may be a solution<br />
* Manifest should be signed<br />
** this will provide some "authenticity" in the event the developer doesn't use SSL<br />
** perhaps hash with shared secret between developer and appstore?<br />
* The rules can be relaxed depending on the set of permissions requested by the manifest<br />
** Dialer app that only requests access to telephony and contacts<br />
*** If the app doesn't request permissions to write/send the data, we may not require the app to be served over SSL (though manifest would still have to be secured)<br />
*** if a MITM does occur in this case, an attacker can't send the data anywhere<br />
<br />
=== Sensitive APIs ===<br />
* Telephony<br />
** potential for fraud<br />
* WebSMS<br />
** potential for fraud<br />
* Contacts<br />
** personal information</div>Dchanhttps://wiki.mozilla.org/index.php?title=File:WebApp_DFD.png&diff=394830File:WebApp DFD.png2012-02-07T17:00:22Z<p>Dchan: Dataflow diagram for webapps</p>
<hr />
<div>Dataflow diagram for webapps</div>Dchanhttps://wiki.mozilla.org/index.php?title=Apps/Security&diff=394827Apps/Security2012-02-07T16:58:36Z<p>Dchan: Created page with "== API permissions == === Dataflow === Link to diagram === What are we trying to solve? === We want to define API permissions taking into account the follow threats # How to pro..."</p>
<hr />
<div>== API permissions ==<br />
=== Dataflow ===<br />
Link to diagram<br />
<br />
=== What are we trying to solve? ===<br />
We want to define API permissions taking into account the follow threats<br />
# How to protect user from malicious app<br />
#* An app should not be able to perform more than it's manifest specifies<br />
# How to protect user from MITM attack<br />
#* This may result in a malicious app scenario<br />
#* We don't want to leak a user's personal information (contacts, messages, voicemail, etc)<br />
<br />
=== Proposed solution ===<br />
* APIs should have separate permissions for read and write/modify.<br />
** e.g. an app that only needs to check call state does not need access to perform calls<br />
* APIs that need internet access should define what domains they need to talk to<br />
* Manifest should be served over SSL<br />
** doesn't protect against a compromised cert<br />
** cert pinning may be a solution<br />
* Manifest should be signed<br />
** this will provide some "authenticity" in the event the developer doesn't use SSL<br />
** perhaps hash with shared secret between developer and appstore?<br />
* The rules can be relaxed depending on the set of permissions requested by the manifest<br />
** Dialer app that only requests access to telephony and contacts<br />
*** If the app doesn't request permissions to write/send the data, we may not require the app to be served over SSL (though manifest would still have to be secured)<br />
*** if a MITM does occur in this case, an attacker can't send the data anywhere<br />
<br />
=== Sensitive APIs ===<br />
* Telephony<br />
** potential for fraud<br />
* WebSMS<br />
** potential for fraud<br />
* Contacts<br />
** personal information</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-01-31&diff=392287Services/Meetings/2012-01-312012-01-31T17:23:17Z<p>Dchan: /* Security */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, North Bridge (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
* Tracy - PTO Fri, Feb. 3rd<br />
<br />
= Ops =<br />
= Engineering =<br />
== Sagrada ==<br />
<br />
=== Metrics (Rob) ===<br />
* Coordinating w/ Metrics team re: load testing preparation<br />
* Finishing up RPM creation for Metlog and dependencies<br />
* Significant progress on Cornice / MozSvc metlog integration<br />
<br />
=== Sauropod (rfkelly & rtilder) ===<br />
<br />
=== SyncStorage (rfkelly) ===<br />
* Documentation for 2.0 API spec posted for comment. Looks good!<br />
* Work on porting to Cornice and BID Auth underway<br />
<br />
=== Queuey (bbangert) ===<br />
<br />
=== Big Lebowski (rtilder) ===<br />
<br />
=== Token Server (Alexis + Tarek) ===<br />
<br />
Cornice:<br />
* Added some missing documentation<br />
<br />
Token server:<br />
<br />
* building Powerhose<br />
* Finished HKDF and salt creation in C++, plugged it to powerhose: https://github.com/ametaireau/tokenserver-crypto<br />
* Starting a c++ lib to deal with signed JSON Web Tokens (JWT): https://github.com/ametaireau/jwtcpp<br />
* working on the HA design with Pete<br />
<br />
== Sync ==<br />
<br />
=== Firefox Sync (rnewman) ===<br />
* Record application logic rewritten to include corner cases - in Firefox 11 and up. Watch out for bug reports!<br />
* Add-on sync goes to beta tomorrow w/ Firefox 11<br />
<br />
=== Android Sync (rnewman) ===<br />
<br />
=== Account Portal (telliott) ===<br />
* Nothing to report here. All work on hold until we know what it looks like in a BID future<br />
<br />
== Notifications ==<br />
=== WebApp/BrowserID support (BIPostal) ===<br />
* deployed new version of bipostal to staging box (bipostal.diresworb.org)<br />
* added graceful exit handler to ppymilter to get better performance reads<br />
* fixed up API and docs for bipostal API<br />
* Pull review<br />
<br />
TODO: <br />
* meet w/ webapps folks to go over notifications.<br />
* try and get b.adida's time for bipostal review.<br />
* pull integration.<br />
<br />
=== Client/Server (jbalogh) ===<br />
* Building up test coverage on the push server (at 86%) so I can rework the storage<br />
* Talked to dougt and sickingj about getting push into Fennec, no blockers came up<br />
* Made by blog post for 2012: http://jbalogh.me/2012/01/30/push-notifications/<br />
* Heading to the WebAPI meeting for more feedback<br />
<br />
== Beta Channel ==<br />
=== Program Launch (mconnor) ===<br />
<br />
= QA =<br />
== Testing and Sign-offs (tracy) ==<br />
* ANS:<br />
** Bug 720933 - [meta] Android Sync 0.3 code drop bugs verified on m-c<br />
** watching for Bug 720934 - [meta] Android Sync 0.4 code drop<br />
* Desktop <br />
** Last week client train verified on M-C end of week<br />
<br />
== API/FunkLoad Scripts (jrgm) ==<br />
== Sync Server (jbonacci) ==<br />
* Change/Maintenance Windows:<br />
** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120124<br />
** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120125<br />
** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120126<br />
** https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120130<br />
<br />
* Focus<br />
** Upcoming Change/Maintenance windows: Sanity testing of Prod, as needed<br />
** Upcoming Deployments: Stage and Prod testing, as needed<br />
<br />
== BrowserID (jbonacci) ==<br />
* Current Release:<br />
* Train 19: Bug 719243 - QA and deploy BrowserID train-2012.01.18 to production<br />
** This train will be completed by mid-day tomorrow (Wednesday)<br />
** Focus right now is on load test debug and testing support for primaries<br />
** Push to Production is schedule for Wednesday afternoon, after which time QA will verify primary support.<br />
<br />
* Upcoming Release<br />
* Train 20<br />
** Focus for this release will be on continued test of primary support and initial support for localization<br />
** First-round language support: en-US, and others TBD<br />
<br />
== BrowserID automation (jrgm) ==<br />
== TPS (jgriffin) ==<br />
<br />
= Deployment Requests =<br />
= Support =<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
= Product =<br />
== Sync ==<br />
=== Firefox 9 ===<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Beyond ===<br />
<br />
== Identity ==<br />
<br />
= Security =<br />
* Android Sync (dchan)<br />
** The J-PAKE review has been completed pending some remaining things by bsmith<br />
** crypto metabug {{bug|722485}}<br />
<br />
= Marketing =<br />
<br />
= Roundtable =<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
=== Beyond ===<br />
<br />
== Notes and actions ==<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchanhttps://wiki.mozilla.org/index.php?title=Services/Meetings/2012-01-24&diff=389832Services/Meetings/2012-01-242012-01-24T17:25:28Z<p>Dchan: /* Sagrada */</p>
<hr />
<div>{{MeetingInfo<br />
|dayOfWeek=Tuesday<br />
|est=12:15 PM<br />
|pst=9:15 AM<br />
|utc=5:15 PM<br />
|room=Mozilla HQ, North Bridge (Vidyo room "Services")<br />
|confId=98616<br />
}}<br />
{{TOC right}}<br />
'''[https://mail.mozilla.com/home/rnewman@mozilla.com/Services%20Team%20Availability.html Who's away?]''': ….<br />
<br />
= Ops =<br />
<br />
Note: [https://intranet.mozilla.org/Services/Ops/Goals#2012_Q1 Goals] do not reflect project timelines discussed in the Work Week pending budget approval.<br />
* If you're curious, I'm asking for another ~$2M for the various projects.<br />
** [https://docs.google.com/spreadsheet/ccc?key=0Ahj0AO5tISWrdGdRMHJXX0lSek9XM05UUlJHTXZIQ3c&hl=en_US#gid=0 Services budget spreadsheet] (rough/untested numbers)<br />
<br />
== BrowserID at PHX1 ==<br />
* Cross-connect in place. Netops has firewall work pending, no ETA available<br />
* Kickstart found broken in PHX1, repairs underway.<br />
<br />
== Production work this week ==<br />
===[https://intranet.mozilla.org/Services/Ops/ChangeWindow_20120124 ChangeWindow 2012-01-24]===<br />
====New/modified changes====<br />
* Deploy cross root intermediate SSL certificate to *.s.m.c, *.browserid.org [{{bug|720478}}]<br />
* Finish innodb rseg alterations to SCL1 and PHX1 Sync databases [{{bug|694234}}]<br />
* Purge pre-ttl history entries [{{bug|687103}}]<br />
<br />
====Unchanged since last week====<br />
* Update SCL2 internal Zeus networking rules to match staging. [{{bug|708444}}]<br />
* Upgrade SCL2 and PHX1 external Zeus software to match internal Zeus and staging. [{{bug|718473}}]<br />
* Reconfigure SCL2 and PHX1 Sync databases to decrease CPU load per request. [{{bug|694222}}]<br />
* Upgrade Sync reg/sreg to fix CEF logging for Infrasec. [{{bug|717073}}]<br />
<br />
= Engineering =<br />
== Sagrada ==<br />
<br />
New engineering wiki framework going up at https://wiki.mozilla.org/Services/Sagrada - Toby will work with people to move their projects under there into that namespace<br />
<br />
=== Token Server (Tarek) ===<br />
<br />
* finishing the crypto bits this week<br />
* security review on the design to start soon<br />
* ongoing dev of the server<br />
* we should meet with Ben B., Ryan K., Toby to define app-to-app auth/<br />
<br />
=== Metlog (Rob) ===<br />
* Metlog MozSvc integration nearly ready for testing<br />
* Lots of conversations w/ other folks re: Metlog requirements<br />
* Have data successfully being pushed into HDFS<br />
* Initial sync-server load testing Coming Soon®<br />
<br />
=== Sauropod (rfkelly & rtilder) ===<br />
Received the Latest! and Greatest! direction for What Is Sauropod?(finish the bottle) on Friday which is essentially a reset back to the original design: Be a token server authorized, encrypted key value store. Developed goals for the quarter for: get an unencrypted but authn/authz implementation in place.<br />
<br />
=== Queuey (bbangert) ===<br />
<br />
Qdo worker library underway, for batch processing of 'jobs' on the queues. Still finishing second draft of Queuey API with new BrowserID assertion handling, wiki will be updated when ready. Acquiring realistic data from Socorro team for creating load testing scripts.<br />
<br />
=== Big Lebowski (rtilder) ===<br />
While I await further Sauropod clarification, I will finish the BigL. Need to come back up to speed on the code.<br />
<br />
== Sync ==<br />
=== Firefox Sync (rnewman) ===<br />
<br />
=== Android Sync (rnewman) ===<br />
<br />
<br />
=== Server (rfkelly) ===<br />
<br />
Meeting to triage bugs and start work on 2.0 yesterday<br />
<br />
=== Account Portal (telliott) ===<br />
<br />
== Notifications ==<br />
=== WebApp/BrowserID support (BIPostal) ===<br />
* post work week work.<br />
* rewrote portions of pymilter to use gevent, saw a 50% speed improvement.<br />
* add'l meetings with ops & qa around bipostal push.<br />
* continuing improvements on milter performance.<br />
* continue review of Push code.<br />
<br />
=== Client/Server (jbalogh) ===<br />
* Have Fennec build + push server that supports the whole flow on Android<br />
* Rebuilding the push server to scale now that the prototype works<br />
<br />
= QA =<br />
* Updated our Q1 [https://intranet.mozilla.org/QA/Q42011_QAgoals#Browser_Technology_QA_Goals goals] from last week's workweek<br />
== Testing and Sign-offs (tracy) ==<br />
* Desktop client train expected ready for testing by EOD Tuesday. Need announcement so MihaelaV in Romania can jump on it over night.<br />
* Continue to pound on Android Native Sync<br />
* Planning<br />
** Working with David Boswell on QA community to improve our transparency, on-ramps and overall services QA community picture for 2012. Tracy is taking the stewardship responsibility off of James plate.<br />
** Moving UI automation to open source image recognition tool Sikuli. The fix for bug 715877 should get us over the hump in automating passing the JPAKE code from client to client<br />
<br />
== API/FunkLoad Scripts (jrgm) ==<br />
<br />
== Sync Server (jbonacci) ==<br />
* 20110124 maintenance window<br />
** Bug 717691 - Android SDK r8 OpenSSL and certificate annoyances<br />
** Bug 720478 - add "cross root" intermediate to production *.s.m.c, *.browserid.org certificates<br />
** Bug 710338 - Upgrade browserid.org SSL cert to EV or crazypants good level<br />
<br />
== BrowserID (jbonacci) ==<br />
* 20110124 maintenance window<br />
** Bug 717691 - Android SDK r8 OpenSSL and certificate annoyances<br />
** Bug 720478 - add "cross root" intermediate to production *.s.m.c, *.browserid.org certificates<br />
** Bug 710338 - Upgrade browserid.org SSL cert to EV or crazypants good level<br />
<br />
Bug 719243 - QA and deploy BrowserID train-2012.01.18 to production<br />
Primaries in and enabled<br />
Localization in code but disabled<br />
Hotfixes and lots of debug<br />
<br />
== BrowserID automation (jrgm) ==<br />
<br />
== TPS (jgriffin) ==<br />
<br />
= Deployment Requests =<br />
<br />
No server trains (unless there's an issue) until 2.0. Makes little sense to deploy incremental improvements on the current code.<br />
<br />
= Support =<br />
<br />
= Metrics =<br />
== Reports and Monitoring (daniel) ==<br />
<br />
= Product =<br />
== Sync ==<br />
=== Firefox 9 ===<br />
=== Firefox 10 ===<br />
=== Firefox 11 ===<br />
=== Firefox 12 ===<br />
=== Firefox 13 ===<br />
=== Firefox 14 ===<br />
=== Beyond ===<br />
<br />
== Identity ==<br />
<br />
= Security =<br />
== Android Sync ==<br />
* Code review of Android sync + J-PAKE is under way<br />
** ETA is unknown<br />
** imelven and dchan looking at [https://github.com/mozilla-services/android-sync/commits/deliverable-0.2 deliverable-0.2 branch]<br />
== Sagrada ==<br />
* yboily has scheduled an initial threat model meeting for today (01-24)<br />
* 11 AM Pacific<br />
* MV 3A - All Your Base (Vidyo 5316)<br />
* The focus of this will to document the relationship and data-flows between the following components:<br />
** Token Server / Authentication Server<br />
** Metrics<br />
** Storage (Sauropod)<br />
** Queuing (Queuey)<br />
<br />
= Marketing =<br />
<br />
= Roundtable =<br />
== 2011Q4 Goals ==<br />
== 2012Q1 Goals ==<br />
== 2012Q2 Goals ==<br />
== 2012Q3 Goals ==<br />
== 2012Q4 Goals ==<br />
=== Beyond ===<br />
<br />
== Notes and actions ==<br />
<br />
== Follow ups from last week ==<br />
== Other issues ==</div>Dchan