November 2, 2007 § 2 Comments
This entry is a brief presentation of an on-going work in progress by my second group of students in ENSI de Bourges, Benjamin Meslin and Jeremy Colombet.
As I detailed in a previous entry, Firefox Extensions — just like their counterparts in Internet Explorer, Safari or Air — are essentially unsafe: once an extension is installed, nothing prevents it from reading, writing or removing files on the user’s hard drive or running arbitrary programs or downloading further instructions from a malicious web site. More subtle problems may also arise, as a malicious extension may read or alter the data of Firefox or of another extension during its execution, so as to, say, steal passwords or reroute transparently from a legitimate website to an identical but forged website.
Now, most recent operating systems have a form of Mandatory Access Control layer (sometimes marketed as “sandboxes”), designed to permit refined security checks of what a program should be able to do when used by a given person and in a given role. Unfortunately, in the current state of things, these layers are completely unadapted to universal clients such as web browsers (or virtual machines, by the way), which act as smaller operating systems themselves, without a clear separation of roles or uses.
That doesn’t mean that MAC can’t be made to work for Firefox, of course. Just that it needs work.
This MAC security layer will take the form of a SpiderMonkey Security Manager. This MAC security layer will let the user (or, more likely, the administrator) define security policies, i.e. decide, for each combination of extension A, identifier B and extension or SpiderMonkey itself or XPCom component C, whether
- an extension A may read fields named B of objects defined by C
- an extension A may write fields named B of objects defined by C
- an extension A may call methods or functions named B of objects defined by C.
The hope is that this security layer will prove both robust enough and flexible enough to be used for actual Firefox extensions and as the support for the sandboxing model required by Prism.
- By the end of November, have defined a precise notion of security policy, as well as a precise grammar for these policies.
- By mid-January, have a first implementation of the Security Manager with the ability to cleanly reject interactions which are not compatible with the security policy. At that point, only extensions are taken into account, not SpiderMonkey itself or XPCom.
- By mid-February, submit that Security Manager for review as a candidate patch to SpiderMonkey.
- Starting in mid-February, work on support for XPCom.
- A set of default security policies to help with administration.
- A nice user-interface to let the user decide at install-time with which policy to accept an extension.