On 7 Aug 2014, at 9:38 pm, Adrian Custer <[email protected]> wrote: > On 8/7/14 12:56 AM, Paul Theriault wrote: > > 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 > > > Hey Paul, > > you write 'there is no reason' and then think of a reason and provide an > exception for that reason 'perhaps so long as'. This reveals you are trying > to work quickly and so are not setting up a clear framework for thinking, > presumably because you do not need to. For me this is difficult since I > personally cannot reason this way when thinking about a 'very real threat’.
The threat I am concerned about here is an attacker with physical access to the device side loading an app with the engineering mode permission. Hopefully vendors will secure their engineering mode APIs, but I am assuming the worst case scenario here and access to engineering mode implies full control of the phone. Its not clear form my comment, but amongst other things, that preference I mention controls whether or not you can attach a debugger to certified apps. My logic is that there is no point preventing side loading of apps with engineering mode permission, if you can just attach the debugger to the system app, grant the permission and then use the API (which is what is possible if devtools.debugger.forbid-certified-apps is set to false). > > Does the FirefoxOS team, or its security sub-group have a pre-defined set of > users and their needs used for the security analysis of FirefoxOS? I would > expect a list of strawman users whose conflicting needs are defined and > agreed about, so that these needs can be reasoned about effectively, > something like: > > Dad Jose --- Just a user, wants all the 'security' he can get > Student Kate --- Builds apps, so needs to side load apps > Developer Luna --- Needs root for debugging and flashing > Engineer Mani --- needs root and low level engineering access > Hacker Nuro --- wants full control > > i.e. j,k,l,m,n with (mostly) increasing levels of access needs. > > If there is such a list, I would be interested to read it so that I could > contextualize these security discussions in the context of the impacts on > these different classes of users. There isn’t as far as I am aware. Typically the discussions have been focused on balancing developer needs (“Luna") vs those of regular users (i.e. your ‘dad' user above). I’m not sure we have the in between case well characterised, but its probably something that could do with attention. - Paul > > Thanks, > ~adrian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
