On 1/21/15 3:57 AM, Paul Theriault wrote:
...snip...
...if have further questions I’ll do my best to answer them.
Thanks,
Paul Theriault
FxOS Security Lead
[1] https://www.mozilla.org/en-US/security/advisories/
[2] https://wiki.mozilla.org/Release_Management/B2G_Landing
Hello Paul,
You probably know, better than most, the work required to turn Firefox
OS into a system in which user security "is not treated as optional."
Unfortunately, Firefox OS today does not treat "{i}ndividuals’ security
and privacy on the Internet {as} fundamental." Rather than tackling head
on the core security issue of Firefox OS---the lack of user
upgradability of the OS and its components---the response of the Firefox
OS team has been to pass the buck, i.e. to suggest that the problem is
entirely in the hands of the providers of mobile telephony and therefore
that the Firefox OS team has no responsibility in these matters.
Furthermore, a more rigorous, formal approach to security issues is
needed to make and track progress on these issues but I don't see anyone
arguing that this work should happen for 3.0.
For me to believe that the Firefox OS team is living up to the Mozilla
Manifesto, I would need to see the Firefox OS team at the very least
TRYING repeatedly to resolve the situation. Perhaps there are
insurmountable obstacles. However, I do not believe, a priori, that all
progress is impossible. Rather I see an organizational structure in
which all work is split into 'functional' teams and therefore the
project as a whole appears unable to tackle fundamental issues like the
overall security of users. Also the lack of a named, overall leadership
or coordinator of the project means that there appears to be no one with
whom to discuss the fundamental, cross-cutting issues that are otherwise
falling through the cracks.
My main question to the Firefox OS team, or to you by default, is: what
work will happen for Firefox OS 3.0 to resolve the lack of security
upgrades of Firefox OS at the gonk level, at the gecko level, and at the
gaia level?
A secondary question would be: how are you going to formalize and
improve the security analysis, system design, testing, monitoring, and
recovery mechanisms for Firefox OS 3.0?
Here below are some issues you might choose to address.
* Integrate your team into the Firefox OS wiki
Preliminarily, you ought to integrate your group into the Firefox OS wiki.
Your group, plans and other information appear to be located at
https://wiki.mozilla.org/Security/B2G/
which probably reflects your origin within some security division of the
Mozilla organization.
The Firefox OS page:
https://wiki.mozilla.org/FirefoxOS
includes things like a supposed organizational diagram:
https://wiki.mozilla.org/FirefoxOS/functionalteams
of the project. This diagram is obviously problematic in that there are
'teams' but no one in charge of solving non-modular, cross-team issues
like improving the work flow, or the code repository and build. In your
case, you can see that 'security' is missing.
There was talk of actually fixing this wiki diagram a month or so ago; I
don't remember who was going to take on that work and don't know what
happened to that plan.
For your part, you should add a link for your team into the list of
'functional teams' at the top of the page and into the 'FirefoxOS Org
Chart' so that readers may learn of your existence. (Ah, I now see an
entry way lower on the page with a link for your group. Does this mean
you are part of the Firefox OS as a 'functional team' or are you
floating in the periphery? Is the security team 'fundamental' or
'optional'?)
* Make a plan to solve security updates
You might want to push the Firefox OS team to solve the security upgrade
issue.
The tiered architecture of Firefox OS leaves lots of room to make
progress on providing security updates to users. As I have said before,
Mozilla has a much easier time of this than most operating systems in
that Mozilla can expect essentially all its users to contact Mozilla
servers regularly during their use of their device. Therefore, the only
limits to upgrade are technological, a domain in which Mozilla is
utterly competent, rather than requiring social outreach to contact users.
Upgrading Gonk could well, I imagine, remain exceedingly difficult since
it involves device specific code, binary drivers of code that can not be
redistributed by default, and low level access to internal storage of
the device. This may require ongoing pressure on your partners something
that may be happening although since that is all behind the scenes the
amount of work involved remains hidden.
Upgrading Gecko seems trivial in comparison. Indeed, Firefox OS is the
only operating system on which Firefox runs that does not allow for user
upgrades of Firefox! It seems improbable therefore that the upgrade of
Gecko on an existing Gonk be impossible. Furthermore, the documentation
you link to suggests this should be possible:
Updates that do not involve Gonk can be done using the Mozilla
System Update Utility.
https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_model
though I have not, as a user, ever seen such a mechanism in use so do
not know what is involved.
Upgrades of Gaia is being partially addressed by moving as many apps as
possible to a security level where the apps are regular marketplace
apps. However, I have not yet heard of efforts to make lower level Gaia
apps upgradable.
The lack of visible work on ensuring users can upgrade regularly at
least parts of their Firefox OS, appears to be a *choice* of the
project. While willing to forgive this choice as a pragmatic decision to
get the OS off the ground, I am no longer willing to let this slide in
plans of version 3.0. Either the Firefox OS team chooses to tackle the
hard work required to make progress on security upgrades or it does not.
In the latter case, I can only conclude that the team does not take the
words of the Mozilla Manifesto seriously.
* Formalize the security analysis
You might also want to take a much more *formal* approach to the
analysis of security issues on Firefox OS.
The current documents and discussion, while extensive, do not appear to
have any formal organization. Right off the top of my head, I can think
of many issues like the strength of the unlock code or the possibility
of encrypting the filesystems on the device which are obvious 'security'
issues but seem to have no home in the existing documentation. The
documents you present in MDN
https://developer.mozilla.org/en-US/Firefox_OS/Security
seem to me haphazard rather than systematic and focused primarily on
combating malicious apps, whereas a Firefox OS user faces many other
security threats.
A formal security analysis involves several components, including:
* a comprehensive threat model,
* a system design which addresses the threats in the model,
* an implementation of the design tested to ensure it deals with
the threats,
* a system to detect failures in the implementation,
* a plan for recovery after failure.
The last of these is my personal measure of 'security' in information
systems---resilience after the inevitable hack demonstrates the strength
of the overall security analysis.
The threat model will require a bunch of work to elaborate. There does
not appear to be any formal threat model defined for Firefox OS. The
best I could find is:
https://developer.mozilla.org/en-US/Firefox_OS/Security/System_security#Goals_and_scope_of_the_Firefox_OS_system_security_model
which is exceedingly limited and missing any discussion of networking
issues or physical access issues. (I do not even understand the third
point.) There is a discussion of 'threats' in the table lower on the
page but there is a caveat above the table in the red 'scope' box which
seems to show all these issues are really about malicious apps first
exploiting gecko and then, using that, exploiting gonk.
Developing a comprehensive threat model is, of course, insanely hard:
the device is networked over multiple channels, the device is mobile and
therefore can readily be lost or accessed by malicious third parties,
the device may be shared with others, the device emits and responds to
radio waves and therefore is highly subject to passive or active
tracking, and on and on. In a world with a hostile network, the stakes
are that much higher. While no one expects Firefox OS to solve all of
the issues, it must be clear which issues the team claims to be tackling
in its security design and which not. As you know, certificate pinning
has been introduced to desktop gecko to tackle yet one more user threat;
it would be good if it were clear in the Firefox OS threat model that
this new threat had *not* been considered yet but will now be considered
(if it will). A formal, explicit threat model allows analysts to see
that progress.
So, in 2015 and/or for version 3.0, I would expect your security team to
be making plans to develop a formal, well elaborated threat model. This
would serve, at the very least, to identify which threats are to be
considered and which are left for later.
The system design for security is discussed extensively in the MDN pages
and is the mostly complete part of the 'security analysis'. Without a
good threat model, it is hard to identify exactly what the design is
addressing. The pages read as a listing of the designs which exist in a
glinux/aosp OS and their use by Firefox OS rather than a list of designs
to mitigate known threats. For example, one threat could be that an
attacker gets a user's phone while they go to the bathroom, plugs it
into a desktop machine, and launches a new process on the device. This
would be a new, malicious piece of software running directly on the
kernel. Is this considered or not in the security design? Which of these
low-level design components would mitigate against this?
So, while the discussion is extensive, it may need reorganization. The
fundamental organization of the documents seem positivist (we have these
pieces) rather than antagonist (we've considered these attacks and they
are solved by these pieces) which is generally a red flag for me. After
all, the ancient Chinese had a very big wall for 'security'; turns out
it didn't work really for that purpose.
The implementation has presumably been extensively tested for security
issues, though I do not know much about this. There is a page on MDN
which implies that it will discuss this testing:
https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Debugging_and_security_testing
but I do not see any real discussion of web apps which attempt to break
out of the IFrame, or that, once allowed to break out of the IFrame, are
then evaluated to be blocked by lower level mechanisms, or of glinux
apps running as processes next to gecko which attempt to exploit lower
level issues like incorrectly set flags on a filesystem. So, while I
expect this is going on, I do not know anything about it.
The monitoring story is non-existent. There is no user facing UI listing
recently started glinux processes, listing software elements which
recently read or wrote to certain filesystem components or the network,
or showing other intrusion signals. There is no UI to list all the apps
which have registered callbacks to be woken in the future. A user of
Firefox OS device has no situational awareness of the OS or way to see
that things are in an extraordinary state. If I leave my device
unattended for five minutes, how do I know that no one installed some
app in my absence which is now running in the background? If an app ever
did break out of its IFrame and then of the Gecko process, how would I
even find out? If the border patrol installed malware while they were
'inspecting' my phone, how would I know that a new app is being launched
on boot? Knowing when security has failed is by far the biggest step in
being secure.
The recovery plan, for a user, seems to be 'buy a new phone'. There is
no way to plug in a phone and re-install the original, as shipped, OS or
a newer update. There is no snapshotting of the OS for future recovery
(i.e. backup). There's not even a way to 'list all installed apps so I
can reinstall them in the future'. Lots of work could be done here with
direct benefits to security and indirect benefits to the user.
So you may want to formalize your work in some way so that everyone can
have more confidence as to where things stand, what is being done, what
ignored for now and so that the failures which will inevitably arise can
be slotted into a formal system for future improvement.
* Make plans for 2015/3.0
You may want to contribute to the plans for 2015 and/or version 3.0 by
addressing some of these security issues.
Unfortunately, the planning for 3.0 is so spectacularly arcane that I am
certainly not going to pitch in that way. The process designers even
invented some kind of new word 'ideation'
https://wiki.mozilla.org/FirefoxOS/v3_ideation
as if collecting ideas, refining them, triaging the ones to work on, and
doing the work was a problem so particular to Mozilla and Firefox OS
that it needed a new vocabulary.
Since that page is a wiki, the managers of Firefox OS could have started
simply by accumulating ideas: "It's a wiki, add an idea and a contact
and, if others like it, we'll refine it later". Instead, they invented:
https://mozilla.app.box.com/s/0uwu07jpc7mljd56vyfc
which is very pretty in its ridiculousness. On planet Mozilla, one
contributor recently coined 'process debt'
http://gregoryszorc.com/blog/2015/01/09/firefox-contribution-process-debt/
which applies perfectly to this plan to make plans for Firefox 3.0. A
better plan might be to gather ideas by any means possible, rather than
inventing a twenty step process to gather ideas.
Ah, it seems the security team has updated its goals for 2015 Q1 as I
wrote this:
https://wiki.mozilla.org/Security/B2G/Goals
cool. However, you will see that I am looking for progress at a much
more fundamental level than the goals you have posted. I approach
security from the perspective of a user who has just bought a device and
is surrounded by threats at all levels; you all seem to approach
security from the perspective of protecting Gecko from the Javascript it
is running. (There was a discussion in 2014 of the risks of allowing
debugging access to the device though I am not sure who was doing the
security analysis for that work.)
Writing this has made me even more despondent about the security
situation in Firefox OS. The Firefox OS team can not solve all that
user's security issues but it sure could figure out which issues the
team thinks it has solved, which it wants to solve next, and which it
will only consider later. In writing this, it is increasingly clear that
I can do nothing to push this forwards beyond raising the issue. I'll
take a look at what you all decide to tackle in 3.0 when you publish
your final plans.
Best of luck,
~adrian
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
