La sicurezza di Firefox OS

Platform Security

La piattaforma Firefox OS usa un modello della sicurezza stratificato con l'obiettivo di mitigare i rischi di violazione ad ogni livello. Contromisure da prima linea e strategie di difesa accurate si uniscono così per fornire globalmente protezioni agli attacchi.

Secure Architecture

Firefox OS collega le applicazioni basate sul web all'hardware sottostante. Consiste in una stack di tecnologie integrate suddivisa nei seguenti livelli:

• Gaia: La suite delle web app responsabili dell'esperienza utente (app costituite da HTML5, CSS, JavaScript, images, media, e così via).
• Gecko:Il livello del runtime delle applicazioni che predispone il framework per l'esecuzione delle app e  Implementa le API Web necessarie per ottenere l'accesso alle funzionalità del dispositivo.
• Gonk: Il Kernel Linux, le librerie di sistema, il firmware e i driver alla base di tutto.
• The mobile device: Lo smarphone con Firefox OS in esecuzione.

Il livello Gecko si comporta come intermediario tra le app web (al livello Gaia) e il telefono. Il compito di Gonk è rende a lui disponibili le funzionalità hardware affinchè possa gestire l'accesso delle app web alle API web. Gecko si impone così come passaggio obbligato ed unico per le richieste d'accesso comportando l'assenza di un accesso diretto o una "back door" al dispositivo. In sostanza Gecko fornisce i permessi e previene gli accessi non autorizzati.

Secure System Deployment

Firefox OS è già intallato negli smartphone. L'immagine di sistema è creata da una sorgente fidata e conosciuta — di solito gli OEM stessi — responsabile dell' assemblaggio, della creazione della build, del test e della firma digitale del pacchetto distribuito.

Le misure di sicurezza sono attive su tutti il livelli della stack. I privilegi del file sistem sono gestiti dalla Linux's access control list (ACLs). Le app di sistema sono installate su di un volume read-only (che diventa read-write solo durante gli aggiornamenti) e generalmente solo le aree con contenuto utente possono essere read-write. Vari componenti hardware del dispositivo hanno sistemi di sicurezza interni implementati come pratica standard dai produttori (ad esempio nei chipset). Il nucleo centrale della piattaforma (Gecko e Gonk) è strutturato per migliorare la sua resistenza contro potenziali attacchi e le caratteristiche di hardcoding del compilatore sono utilizzate per questo scopo ove possibile. Per altri dettagli vedere sicurezza del Runtime.

Secure System Updates

I seguenti aggiornamenti e patch a Firefox OS sono diffusi tramite un processo sicuro elaborato da Mozilla per assicurare il mantenimento dell'integrità dell'immagine sistema sul dispositivo. Anche l'aggiornamento è fornito da fonti affidabili e conosciute— di solito dagli OEM — responsabili dell'assemblggio, della creazione della build build, del test e della firma digitale del pacchetto distribuito.

Gli aggiornamenti di sistema possono influire su tutta la stack o solo su porzioni porzioni della stessa. Se gli aggiornamenti includono modifiche a Gonck sarà usto il processo FOTA (Firmware Over the Air) per l'installazione. Questa metodologia può anche includere cambiamenti su qualsiasi altra parte della stack, inclusa la gestione del dispositivo (FOTA, firmware / driver), la gestione delle impostaioni (Firefox OS settings), gli aggiornamenti sulla sicurezza, Gaia, Gecko, e altro.

GLi aggiornamenti che invece non includono Gonck possono esere effettuati usando la Mozilla System Update Utility. Firefox OS usa lo stesso framework per gli aggiornamenti, i processi, e per il formato Mozilla ARchive (MAR) (usato per i pacchetti di aggiornamento) di Firefox per Desktop.

un servizio integrato — che piò essere fornito dagli OEM — controlla regolarmente se sono disponibili aggiornamenti per il dispositivo in uso, se ve ne sono viene proposta all'utente l'installazione. PRima che il processo di aggiornamento venga avviato è controllato se lo spazio disponibile nel dispositivo è sufficiente e che la distribuazione sia verificata per:

• Provenienza (verifica la locazione della sorgente protocol:domain:port dell'aggiornamento di sistema e del manifesto)
• Integrità dei File (SHA-256 hash check)
• Firma digitale (controllo certificato rivolto ai trusted root)

Le seguente misure di sicurezza sono applicate durante il processo di aggiornamento:

• Mozilla consiglia e si aspetta che il recupero degli aggiornamenti avvenga tramite connessioni SSL.
• Una forte verifica crittografica è richiesta prima dell'installazione di un pacchetto firmware.
• Tutto l'aggiornamento deve essere scaricato in una specifica locazione sicura prima dell'installazione .
• Il sistema deve essere in uno stato di sicurezza prima che inizi il processo, senza nessuna app in esecuzione.
• Le chiavi devono essere salvate in una locazione sicura nel dispositivo.

Sono disposti controlli rigorosi per assiucurare che l'aggiornamento sia propriamente applicato al telefono.

Sicurezza nelle app

Firefox OS usa una precisa strategia per proteggere lo smartphone da applicazioni dannose o intrusive; questa consiste in una serie di meccanismi come: livelli di permessi impliciti basati sul modello di affidabilità delle app, modlità sandbox in runtime, accesso hardware riservato alle sole API, modello dei permessi robusto e  processo sicuro di installazione e aggiornamento. Per dettagli tecnici consultare Sicurezza delle applicazioni.

In Firefox OS, tutte le applicazioni sono app web — programmi scritti in HTML5, JavaScript, CSS, media, ed altre tecnologie web (le pagine web visualizzate nel browser non sono considerate app web in questo contesto). Poichè non ci sono applicazioni binare ("native") installate dall'utente, tutto l'accesso al sistema è delegato strettamente alle API Web. Anche l'accesso al file system è veicolato dalle API Web e da un database back-end SQLite — non c'è accesso diretto dalle app ai file salvati nella scheda SD.

Firefox OS limita e espande la quantità di risorse accessibili o utilizzabili da un'app, mentre inoltre supporta un ampio spettro di applicazioni con vari livelli di permesso. Mozilla ha inoltre implementato uno stretto controllo su che tipo di applicazioni possono accedere alle API Web. Per esempio, solo app certificate (cioè già incluse nel telefono) possono avere accesso all'API Telephony. L'app Dialer hai i privilegi per L'API Telephony per effettuare telefonate, ma ciò non è vero per tutte le app certificate.

Questo previene tutte quelle situazioni in cui, per esempio, le app di terze parti avviano telefonate verso numeri a pagamento, provocando un grosso impatto sulla bolletta telefonica.

Comunque anche altre app OEM selezionate possono avere accesso alle API Telephony. Per esempio, un operatore può fornire un sistema di gestione del proprio account telefonico, per il supporto dei clienti.

Applicazioni affidabili e non

Firefox OS divide le app nei seguenti tipi:

Il livello di affidabilità determina, in parte, le capacità dell'applicazione di accedere alle funzionalià del dispositivo.

• Le app certificate hanno accesso alla maggior parte delle operazioni disponibili tramite API Web.
• Le app privilegiate hanno permessi su un sottoinsieme delle API Web accessibili dalle app certificate.
• Le restanti hanno disponibile un sottoinsieme ancora più ridotto, ossia sono disponibili solo quelle API Web che hanno sistemi di sicurezza sufficienti all'esposizione a contenuto non affidabile.

Alcune operazioni, come l'accesso alla rete, sono considerate implicite in ogni app. In generale, più l' operazione eseguita è sensibile, più il livello di affidabilità dev'essere elevato (ad esempio, comporre un numero e accedere alla lista dei contatti sono operazioni sensibili).

Principio dei minimi permessi

Per le web app, il framework della sicurezza di Firefox OS segue il principio dei minimi permessi: partire con il livello di permessi minimo, per poi aggiungere altri privilegi solo se necessari e ragionevoli. Di default, un'applicazione è pressochè priva di autorizzazioni, a un livello comprabile a quello delle app non affidabili. Se l'applicazione effettua chiamate alle API che necessitano di autorizzazioni aggiuntive, deve elencarle nel manifest dell'applicazione (che verrà approfondito successivamente in questo documento). Gecko si occuperà di considerare le richieste ed eventualmente di garantire l'accesso alle API Web richieste dall'applicazione, ma solo se le condizioni di privilegio sono espresse esplicitamente nel manifest. Gecko soddisferà le richieste solo se il type della app Web (certificate, affidabili, o web) è sufficientemente qualificato per l'accesso.

Il processo di revisione delle app privilegiate Marketplace

Affinchè un app diventi privilegiata, il fornitore dell'applicazione deve inviarla su in Marketplace autorizzato per l'analisi. Il Marketplace sottopone l'applicazione ad una revisione precisa del codice: verifica la sua autenticità e integrita, assicurando che i permessi richiesti siano effettivamente usati per le finalità indicate, verificando che l'uso dei permessi impliciti sia appropriato e validando ogni interfaccia tra contenuto delle app privilegiate e non, abbiano le appropriate restrizioni per prevenire attacchi che sfruttino l'elevazione dei privilegi. Il Marketplace ha la responsabilità di assicurare che le app non abbiano comportamenti ambigui con i privilegi assegnati.

Dopo che un applicazione è stata approvata, il suo manifesto è firmato digitalmente dal Marketplace e reso disponibile per il download da parte degli utenti. La firma assicura che, anche se lo store online fosse hackerato, l'hacker non possa installare contenuto arbitrario o codice maligno sul dispositivo. Grazie a questo processo di veto le app del Marketplace possono avere accesso ad una più ampia gamma di privilegi rispetto al normale contenuto web. 

App Packaged Hosted

Le app per Firefox OS possono essere packaged (salvate sul telefono) o hosted (Salvate su un server remoto, con il solo manifest sul dispositivo). Ci sono delle differenze nel modo in cui la sicurezza è gestita in ogniuna di esse. Inoltre le app packaged e hosted sono eseguite in sandbox, cosa che verrà approfondita più avanti in questo documento.

App Packaged

Un'app packaged consiste in un file ZIP contenete sia le risorse (HTML5, CSS, JavaScript, images, media) che un manifest contenente una dichiarazione esplicita di asset con i relativi hash. Le app certificate e prvilegiate devono essere del tipo packaged perchè il manifest deve essere firmato digitalmente. Quando un utente richiede un app il file ZIP è scaricato sul dispositivo e il manifesto viene letto da una locazione conosciuta all'interno del file ZIP. Durante il processo di installazione gli assets dell'applicazione sono verificati e rimangono salvati locamente nel pacchetto. L' esplicitazione di tutti i permessi, mostrando all'utente come l'app intende maneggiare i dati personali, è richiesta al runtime e deve rimanere tale per default.

Per fare riferimento alle risorse in un app packaged si usa un URL con all'inizio la dicitura app: nel seguente formato:

app://identificatore/percorso_interno_al_file_zip/file.html

dove app:// rappresenta il punto di montaggio del file ZIP, e l'identificatore è un UUID generaato all'installazione dell'app nel telefono. Questo meccanismo assicura che le risorse siano identificate con un app: URL che contiene il file ZIP. Il percorso in app: è relativo, quindi i collegamenti alle risorse nel file ZIP sono permessi.

Mentre le app packaged sono create principalmente per essere app certifcate o privilegiate, anche le normali app wab possono essere packaged. However, they do not gain any increase in trust or permissions access simply because they are packaged.

App Hosted

Le app Hosted sono posizionate su un server web e caricate tramite HTTP. Solo il manifest è salvato sul dispositivo le restanti comonenti si trovano su server remoti. Certe API sono disponibili solo alle app certificate o privilegiate (ossia privilegiate). Perciò, un'app hosted non potrà avere accesso alle operazioni delle API Web che richiedono lo status di app privilegiate o certificate.

Dal punto di vista della sicurezza le app hosted sono trattaate come comuni siti web. Un'app hosted è caricata invocando un URL hard-coded, e completamente qualificato che punta alla pagina d'avvio nella cartella radice dell'app su quel server web. Una volta che un'app hosted è caricata, il telefono la collega alle pagine usando gli stessi URL che sono usati nonrmalmente navigando nel sito web.

App Manifest

Un manifest di una Open Web App contiene informazioni che un browser Web necessita per interagire con un'app, è un file JSON con (almeno) un nome e una descrizione per l'applicazione. Per maggiori dettagli, fare riferimento a FAQ sui manifest delle app.

Manifest d'esempio

il codice seguente è un esempio di manifest con alcune semplici impostazioni:

{
  "name": "Il titolo dell'applicazione va qui",
  "description": "La descrizione dell'applicazione va qui",
  "launch_path": "/",
  "icons": {
    "128": "/img/icon-128.png"
  },
  "developer": {
    "name": "il tuo nome o quello dell'organizzazione",
    "url": "https://la-tua-homepage-va-qui.org"
  },
  "default_locale": "it"
}

Le impostazioni di sicurezza del Manifest

Il manifest può contenere varie informazioni, incluse le seguenti impostazioni sulla sicurezza:

Firefox OS requires that the manifest be served with a specific mime-type (application/x-web-app-manifest+json) and from the same fully-qualified host name (origin) from which the app is served. This restriction is relaxed when the manifest app (and thus the app manifest) is same-origin with the page that requested the app to be installed. This mechanism is used to ensure that it's not possible to trick a website into hosting an application manifest.

Sandboxed Execution

This section describes application and execution sandboxes.

Application Sandbox

The Firefox OS security framework uses sandboxing as a defense-in-depth strategy to mitigate risks and protect the mobile phone, platform, and data. Sandboxing is a way of putting boundaries and restrictions around an app during run-time execution. Each app runs in its own worker space and it has access only to the Web APIs and the data it is permitted to access, as well as the resources associated with that worker space (IndexedDB databases, cookies, offline storage, and so on).

The following figure provides an overview of this security model.

By isolating each app, its impact is contained within its own worker space and it cannot interfere with anything (such as other apps or their data) outside of that worker space.

Execution Sandbox

B2G (Gecko) runs in a highly-privileged system process that has access to hardware features in the mobile phone. At runtime, each app runs inside an execution environment that is a child process of the B2G system process. Each child process has a restricted set of OS privileges — for example, a child process cannot directly read or write arbitrary files on the file system. Privileged access is provided through Web APIs, which are mediated by the parent B2G process. The parent ensures that, when a child process requests a privileged API, it has the necessary permission to perform this action.

Apps communicate only with the B2G core process, not with other processes or apps. Apps do not run independently of B2G, nor can apps open each other. The only “communication” between apps is indirect (for example, when one app sets a system alarm and another app triggers a system notification as a result of it), and is mediated through the B2G process.

Hardware Access Only via the Web API

Web apps have only one entry point to access mobile phone functionality: the Firefox OS Web APIs, which are implemented in Gecko. Gecko provides the sole gateway to the mobile device and underlying services. The only way to access device hardware functionality is to make a Web API call. There is no “native” API and there are no other routes (no “back doors”) to bypass this mechanism and interact directly with the hardware or penetrate into low-level software layer.

Security Infrastructure

The following figure shows the components of the Firefox OS security framework:

• Permission Manager: Gateway to accessing functionality in the Web API, which is the only access to the underlying hardware.
• Access Control List: Matrix of roles and permissions required to access Web API functionality.
• Credential Validation: Authentication of apps/users.
• Permissions Store: Set of privileges required to access Web API functionality.

Permissions Management and Enforcement

Firefox OS security is designed to verify and enforce the permissions granted to web apps.

The system grants a particular permission to an app only if the content requests it, and only if it has the appropriate permissions requested in the app’s manifest. Some permissions require further authorization from the user, who is prompted to grant permission (as in the case of an app requesting access to the user’s current location). This app-centric framework provides more granular control over permissions than traditional role-centric approaches (in which individual roles are each assigned a set of permissions).

A given Web API has a set of actions and listeners. Each Web API has a required level of permission. Every time a Web API is called, Gecko checks permission requirements (role lookup) based on:

• Permissions associated with calling app (as specified in the manifest and based on the app type.)
• Permissions required to execute the requested operation (Web API call.)

If the request does not meet the permission criteria, then Gecko rejects the request. For example, untrusted apps cannot execute any Web APIs that are reserved for trusted apps.

Prompting Users for Permission

In addition to permissions that are implicitly associated with the web apps, certain operations require explicit permission from the user before they can be executed (for example, "can the web app access your camera?"). For these operations, web apps are required to specify, in their manifest, their justification for requiring this permission. This data usage intention informs users about what the web app intends to do with this data if permission is granted, as well as any risk involved. This allows users to make informed decisions and maintain control over their data.

Secure App Update Process

For app upgrades and patches to a privileged app, app providers submit the updated package to an authorized Marketplace, where it is reviewed and, if approved, signed and made available to users. On Firefox OS devices, an App Update Utility periodically checks for app updates. If an update is available, then the user is asked whether they want to install it. Before a update is installed on the mobile device, the package is verified for:

• Update origin (verify the source location protocol:domain:port of the update and manifest)
• File integrity (SHA-256 hash check)
• Code signature (certificate check against a trusted root)

Rigorous checks are in place to ensure that the update is applied properly to the mobile phone. The complete update package must be downloaded in a specific and secure location before the update process begins. Installation does not overwrite any user data.

Device Security (Hardware)

Security mechanisms for the mobile device hardware are typically handled by the OEM. For example, an OEM might offer SIM (Subscriber Identity Module) card locks, along with PUK (PIN Unlock Key) codes to unlock SIM cards that have become locked following incorrect PIN entries. Contact your OEM for details. Firefox OS does allow users to configure passcodes and timeout screens, which are described in the next section.

Data Security

Users can store personal data on their phone that they want to keep private, including contacts, financial information (bank & credit card details), passwords, calendars, and so on. Firefox OS is designed to protect against malicious apps that could steal, exploit, or destroy sensitive data.

Passcode and Timeout Screens

Firefox OS allows users to set a passcode to their mobile phone so only those who supply the passcode can use the phone. Firefox OS also provides a timeout screen that is displayed after a configurable period of phone inactivity, requiring passcode authentication before resuming use of the phone.

Sandboxed Data

As described earlier, apps are sandboxed at runtime. This prevents apps from accessing data that belongs to other apps unless that data is explicitly shared, and the app has sufficient permissions to access it.

Serialized Data

Web apps do not have direct read and write access to the file system. Instead, all access to storage occurs only through Web APIs. Web APIs read from, and write to, storage via an intermediary SQLite database. There is no direct I/O access. Each app has its own data store, which is serialized to disk by the database.

Data Destruction

When a user uninstalls an app, all of the data (cookies, localStorage, IndexedDB, and so on) associated with that application is deleted.

Privacy

Mozilla is committed to protecting user privacy and user data according to its privacy principles (https://www.mozilla.org/privacy/), which stem from the Mozilla Manifesto (https://www.mozilla.org/about/manifesto.html). The Mozilla Firefox Privacy Policy describes how Mozilla collects and uses information about users of the Mozilla Firefox web browser, including what Firefox sends to websites, what Mozilla does to secure data, Mozilla data practices, and so on. For more information, see:

• https://www.mozilla.org/en-US/legal/privacy/firefox.html
• https://blog.mozilla.org/privacy/
• https://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones

Firefox OS implements these principles by putting the control of the user data in the hands of the user, who gets to decide where this personal information goes. Firefox OS provides the following features:

• Do Not Track option
• ability to disable Firefox browser cookies
• ability to delete the Firefox OS browsing history