So to summarise the security requirements &properties here: - Engineering mode will be disabled until the dialer (or other certified app) initiates the special web activity - Even with engineering mode enabled, only an app with the certified “engineering-mode” (or similar) permission can access the API which can be extended by the vendor
I’d make a couple notes here: - There is no reason for side loaded apps to have this permission, and its present a very real threat of local privilege escalation, so we should explicitly prevent side loading apps which have access to these APIs (perhaps so long as the devtools.debugger.forbid-certified-apps pref is true, so engineering build phones can still access them). - The dialer should take observe lock state - we need to prevent enabling engineering mode from the dialer presented by the lockscreen ( i think your patch does this already though since it only changes the dialer, not the lockscreen dialer) We should also provide security guidance to Partners implementing engineering mode functionality to reduce the risk of security issues here. Does that sound reasonable? - Paul On 4 Aug 2014, at 12:39 am, Evelyn Hung <[email protected]> wrote: > Hi Jonas, > > Yes, we basically follow the setup in bug 997564, except (6). > Instead of inventing a new certified WebAPI, we reuse IAC for establish > the connection between the XPCOM module and the engineering mode app. > > So here's our plan: > > - follows (1) to (5): launch the certified engineering mode app via > a 'internal-system-engineering-mode' webactivity fired by a certified > app (Dialer app now). Add a XPCOM interface so partners can do their > own implementation. > > - The XPCOM component watches the engineering mode app launched, and > connect to it via IAC. So they can exchange information in any > format/protocol they want. > For that to work we will implement a chrome to content IAC interface. > > Note that patches in bug 997564 are just a prototype for partner testing. > We are polishing it. :) > > > Regards, > Evelyn > > > ----- Original Message ----- >> Hi All, >> >> We have many times debated how to handle engineering mode. Various >> partners have so far been adding in custom solutions on their own >> branches, but it would be good to find a better solution. >> >> Below is one proposed solution, though I'm definitely open to other >> ones. However the goals I'd like to accomplish are: >> >> A) The commands that can be triggered in the service menu is going to >> be fairly OEM specific and not something that makes sense to build >> into Gecko as cross-device-cross-device code. >> B) The smaller Gecko/Gaia changes needed by OEMs the better. This is >> to simplify porting the implementation forward to future FirefoxOS >> releases. >> C) We would like to one day be able to roll out updates to phones >> without requiring OEMs to reapply their own changes to the updated >> release. >> D) The back-end of the service menu needs to be at least partially >> implemented in C++. I.e. some of the commands that can be triggered >> can't be implemented using the currently exposed APIs, even including >> certified APIs. >> F) The service menu UI should be implemented as a separate FirefoxOS >> HTML app. I.e. we don't want to use some other rendering mechanism >> than what we already have. And we don't want to have to add a lot of >> engineering mode code to any of the normal gaia apps. >> G) There shouldn't need to be a user visible icon on the home screen >> for launching engineering mode. >> H) It would be ideal, though not strictly required, if it was possible >> to launch engineering mode by using a key combination in the dialer >> app since this is how OEMs are used to doing it today. >> >> Based on that I recommend the following setup: >> >> 1) Add a gaia-setting for "key combination in dialer that triggers >> service mode". >> 2) Change the dialer app to read this setting and wait for the correct >> key combination to be triggered. >> 3) When the combination has been hit, let the dialer app launch an >> activity called "internal-system-engineering-mode". >> 4) Change web activities to enforce that activity names starting with >> "internal-system-" can only be initiated and handled by certified >> apps. >> 5) Add a XPCOM interface and an XPCOM contract-id for engineering >> mode. The interface would have functions for >> getValue/setValue/message. See below >> 6) Create a certified-only WebAPI which handles the IPC and security >> checks to enable an app to use the above XPCOM interface. >> >> The XPCOM interface would look something like: >> >> // Implemented by engineering-mode library >> interface nsIEngineeringMode >> { >> DOMString getValue(in DOMString name); >> void setValue(in DOMString name, in DOMString value); >> void setMessageHandler(in nsIEngineeringModeMessageHandler handler); >> } >> >> interface nsIEngineeringModeMessageHandler >> { >> void handleMessage(DOMString message); >> } >> >> and the contract id would be something like >> "@mozilla.org/b2g/engineering-mode;1" >> >> >> And the WebAPI would look something like >> >> interface EngineeringMode { >> Promise<DOMString> getValue(DOMString name); >> void setValue(DOMString name, DOMString value); >> attribute EventHandler onmessage; >> } >> >> partial interface Navigator { >> readonly attribute EngineeringMode engineeringMode; >> } >> >> >> >> Once we have this, it means that OEMs could implement engineering mode >> by simply dropping a shared library in the Gecko profile which >> implements the needed backend. Then preinstall a certified app which >> handles the internal-system-engineering-mode webactivity. This app >> could then use any existing certified API as well as new >> EngineerinMode API, to implement the service menu. >> >> Obviously this app would be marked as hidden as to prevent it from >> showing up on the homescreen. >> >> / Jonas >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
