diff options
Diffstat (limited to 'files/es/archive/b2g_os/security')
3 files changed, 0 insertions, 445 deletions
diff --git a/files/es/archive/b2g_os/security/application_security/index.html b/files/es/archive/b2g_os/security/application_security/index.html deleted file mode 100644 index 0573a493e0..0000000000 --- a/files/es/archive/b2g_os/security/application_security/index.html +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Seguridad en aplicaciones -slug: Archive/B2G_OS/Security/Application_security -translation_of: Archive/B2G_OS/Security/Application_security ---- -<div> - <div class="overheadIndicator draft"> - <p><strong>Borrador</strong><br> - Esta página no está completa.</p> - -</div></div> -<p>Los controles clave en la seguridad de las aplicaciones web introducidas por FirefoxOS son:</p> -<ul> - <li>Las aplicaciones web son explicitamente instaladas y lanzadas explicitamente, en vez de ser casualmente navedas con el navegador. Las aplicaciones deben ser instaladas antes de ser usadas, y controles de seguridad gobiernan la actualización y desintalacion de las aplicaciones para proteger al usuario.</li> - <li>El acceso a las nuevas APIs web esta controlado por un sistema de permisos, donde una aplicación debe declarar los permisos que intenta usar antes de ser instalada. Para ganar acceso a APIs más poderosas, las aplicaciones deben cumplir ciertos requerimientos, y ser revisadas, aprobadas y firmadas por una tienda de aplicaciones.</li> - <li>Las aplicaciones web funcionan dentro de un sandbox así solo pueden ver sus propios recursos (cookies, almacenamiento offline, bases de datos indexadas, etc.). Inclusive si dos aplicaciones cargan la misma URL, estas dos páginas no son consideradas del mismo origen al estar corriendo dentro de dos aplicaciones separadas.</li> -</ul> -<h3 id="Tipos_de_aplicaciones">Tipos de aplicaciones</h3> -<p>FirefoxOS soporta tres tipos de aplicaciones web:<span id="cke_bm_73S" style="display: none;"> </span><span id="cke_bm_71S" style="display: none;"> </span> "<strong>web</strong>"<span id="cke_bm_73E" style="display: none;"> </span><span id="cke_bm_71E" style="display: none;"> </span>,<span id="cke_bm_74S" style="display: none;"> </span> "<strong>privilegiadas</strong>"<span id="cke_bm_74E" style="display: none;"> </span> y "<strong>certificadas</strong>". Un tipo de aplicacion es declarado en su <a href="/en-US/docs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">manifest</a>, y determina la lista de permisos que puede solicitar.</p> -<ul> - <li><strong>Aplicaciones web:</strong> la mayor parte de las aplicaciones de terceros serán aplicaciones "web", el cual es el tipo por defecto, y no garantiza a la aplicación ningún permiso adicional aparte de aquellos ya expuestos en la web. Las aplicaciones wev pueden ser instaladas desde cualquier sitio web, sin ningún otro tipo de verificación. También pueden ser <a href="/es/docs/Aplicaciones/Packaged_apps">empaquetadas</a> pero esto no les concede ningún permiso adicional.</li> - <li><strong>Aplicaciones privilegiadas:</strong> Estas aplicaciones pueden solicitar mayores permisos, y como tales las aplicaciones <em>privilegiadas</em> deben ser verificadas y firmadas por una tienda de aplicaciones.</li> - <li><strong>Aplicaciones certificadas:</strong> actualmente las aplicaciones certificadas solo pueden ser preinstaladas en los dispositivos.</li> -</ul> -<p>Para más detalles de los tres tipos, véase la documentación del <a href="/en-US/docs/Apps/Manifest#type" title="/en-US/docs/Apps/Manifest#type">App Manifest</a>.</p> -<h3 id="Entrega_de_aplicaciones">Entrega de aplicaciones</h3> -<p>Las aplicaciones pueden ser pueden ser entregadas por dos mecanismos diferentes en Firefox OS: alojadas o enpaquetadas. Las aplicaciones web regulares pueden ser entregadas por cualquier mecanismo, mientras que las aplicaciones privilegiadas deben ser empaquetadas.</p> -<h4 id="Aplicaciones_alojadas"><span class="mw-headline" id="Hosted_apps">Aplicaciones alojadas</span></h4> -<p>Una aplicación alojada consiste simplemente en un archivo <a href="/es/docs/Aplicaciones/Manifest">manifest</a> en el servidor del desarrollador. A menudo el manifest apunta también a un manifest de appcache que permite a la aplicación ser cacheada para un arranque más rápido y para habilitar el uso offline, pero de otra manera no afecta a la aplicación para nada. Desde el punto de vista de la seguridad, las aplicaciones alojadas funcionan como un sitio web normal. Cuando una aplicación alojada es cargada, la URL de las paginas cargadas son las URL que aquellas paginas tendrian normalmente en su servidor web. Así para enlazar a una página web específica o recurso en la aplicación, la misma URL es usada como cuando una URL es usada para enlazar a esa página o URL en un sitio web específico.</p> -<h4 id="Aplicaciones_empaquetadas">Aplicaciones empaquetadas</h4> -<p><strong>Una aplicación empaquetada</strong> es una Open Web App que tiene todos sus recursos (HTML, CSS, JavaScript, app manifest, etc.) contenidos en un archivo zip, en vez de tener sus recursos en un servidor web. Para más detalles en este formato, vease <a href="/es/docs/Aplicaciones/Packaged_apps">aplicaciones empaquetadas</a>. </p> -<h3 id="Instalación_de_aplicaciones">Instalación de aplicaciones</h3> -<p>Las aplicaciones son instaladas mediante la <a href="/es/docs/Aplicaciones/Apps_JavaScript_API" title="/en-US/docs/JavaScript_API">API Javascript de aplicaciones</a>:</p> -<ul> - <li>Aplicaciones alojadas: las aplicaciones alojadas son instaladas llamando <code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.install" title="/en-US/docs/Web/API/Apps.install">install</a>(URL_del_manifest)</code>, donde URL_del_manifest es una URL que especifica la ubicación de la aplicación. Para más detalles véase <a href="/en-US/docs/DOM/Apps.install">Instalando aplicaciones</a>.</li> - <li>Aplicaciones empaquetadas: las aplicaciones alojadas son instaladas llamando <code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.installPackage" title="/en-US/docs/Web/API/Apps.installPackage">installPackage</a>(URL_del_paquete)</code>. Para las aplicaciones empaquetadas el manifest principal de la aplicación es guardado dentro del paquete mismo, entonces este es firmado. Hay un segundo 'mini-manifest' el cual es usado para arrancar el proceso de instalación. Vease <a href="/es/docs/Web/API/Apps.installPackage">Instalando aplicaciones empaquetadas</a> y <a href="/es/docs/Web/Apps/Developing/Packaged_apps/Packaged_apps">Aplicaciones empaquetadas</a> para más información.</li> -</ul> -<p>Para asegurarse que una aplicación realmente quiere ser instalada como una aplicación web tenemos que asegurar que no es posible engañar a un sitio web para que aloje un manifest de aplicación. Esto es hecho exigiendo que el manifest sea servido con un mime-type específico, "application/x-web-app-manifest+json". Esta restricción se relaja cuando la aplicación manifest, y por lo tanto el manifest de aplicación, es del mismo origen que la página que hizo el pedido para instalar la aplicación.</p> -<h3 id="Actualizaciones"><span class="mw-headline" id="Updates">Actualizaciones</span></h3> -<p>El proceso de actualizaciones para las aplicaciones está descrito aquí: <a href="/en-US/docs/Apps/Updating_apps" title="Apps/Updating_apps">Actualizando apliaciones [en-US]</a></p> -<h2 id="Permisos">Permisos</h2> -<p>Se le pueden otorgar privilegios adicionales a las aplicaciones por sobre los privilegios de un sitio normal. Por defecto las aplicaciones tienen los mismos permisos que las páginas web normales. Para poder ganar permisos adicionales, el primer paso es enumerar los permisos adicionales que esta necesita en el manifest de la aplicación.</p> -<h3 id="Declaración_del_manifest">Declaración del manifest</h3> -<p>Para cada permiso adicional que la aplicación quiera, el manifest debe enumerar el permiso junto con una descripción sencilla de por qué la aplicación necesita ese permiso. Por ejemplo si una aplicación quiere usar la API<a href="/es/docs/DOM/window.navigator.geolocation" title="/en-US/docs/Web/API/window.navigator.geolocation"> navigator.geolocation</a>, debe incluir en su archivo manifest:</p> -<pre class="brush: html">"permissions": { - "geolocation":{ -<code class="language-js"><span class="token string"> "description"</span><span class="token punctuation">:</span> <span class="token string">"Requerido para el autocompletado en la pantalla compartida"</span><span class="token punctuation">,</span></code> - } -}, -</pre> -<p>Esto permite a la aplicación indicar el permiso para la geolocalización, de la misma manera que una página web normal lo haría. Para más detalles acerca de los manifest, véase <a href="/en-US/docs/Apps/Manifest" title="Apps/Manifest">App manifest</a>.</p> -<p>Nota: Actualemente la intensión de uso de los permisos no se muestran al usuario - véase <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=823385" title="https://bugzilla.mozilla.org/show_bug.cgi?id=823385">bug 823385</a>.</p> -<h3 id="Otorgando_permisos">Otorgando permisos</h3> -<p>Cuando los permisos son solicitados en el manifest, el permiso es definido como "allow" (permitir) o "prompt" (preguntar). Los permisos permitidos son otorgados al ser declarados en el manifest sin necesidad de más aprobaciones. Para permisos preguntados, se le pide el permiso al usuario la primera vez que la aplicación accede a la API relacionada, y tiene que tomar la decisión antes de que el acceso a la API sea otorgado. En general, Firefox OS solo pide a los usarios acerca de los permisos cuando estos pueden tener un impacto en la privacidad, y es razonable para el usuario entender que esta siendo pedido. Por ejemplo el acceso a los contactos es pedido, sin embargo el acceso para hacer una conección TCP es simplemente garantizada porque no razonable para un usuario entender las implicaciones de seguridad implicadas en permitir estos permisos. El uso de permisos "allow" es revisado como parte de la revisión de seguridad del Marketplace para asegurar que los usuarios se encuentran protegidos.</p> -<h3 id="Revocando_permisos">Revocando permisos</h3> -<p>Los usuarios pueden cambiar su opinión en cualquier momento acerca de permisos "prompt" en cualquier momento, y puede revocar los permisos a través de la aplicación de configuracion de Firefox OS. Los permisos "allow" no son configurables por el usuario.</p> -<h2 id="Sandbox_de_las_aplicaciones_Web">Sandbox de las aplicaciones Web</h2> -<h3 id="Información_almacenada_por_aplicación"><span class="mw-headline" id="Data_stored_per_app">Información almacenada por aplicación</span></h3> -<p>Cada aplicación corre su propio sandbox, eso significa que toda la información guardada por una aplicación es separada de toda la información guardada por cualquier otra aplicación. Esto incluye cosas como información de cookies, información almacenada localmente, bases de datos indexadas localmente, y permisos de sitios.</p> -<p>Esto significa que si un usuario instaló dos aplicaciones, la Aplicación A y la Aplicación B, estas tendrán cookies completamente diferentes, diferente información local, y diferentes permisos. Esto se aplica inclusive si ambas aplicaciónes abren un <iframe> que apunta hacia el mismo origen. Por ejemplo, si ambas aplicaciones A y B abren un <iframe> que apunta a "<a class="external free" href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>", ambas mostrarán la misma página web, sin embargo el sitio será cargado y mostrado con diferentes cookies en las dos aplicaciones.</p> -<p>Un resultado de esto es que si un usuario se registra en, por ejemplo Facebook, cuando está usando la aplicación A, esto afecta la capacidad de B para interactuar con la cuenta del usuario en Facebook. La cookie que que usa facebook para registrarse cuando el usuario está usando la aplicación A está solo disponible para la aplicación A. Si la aplicación B abre un <iframe> a Facebook, la cookie no estará allí y entonces cuando la aplicación B abre Facebook, recibe la pantalla de registro en vez de la cuenta del usuario.</p> -<h3 id="Las_aplicaciones_no_se_pueden_abrir_entre_ellas"><span class="mw-headline" id="Apps_can.27t_open_each_other">Las aplicaciones no se pueden abrir entre ellas</span></h3> -<p>Esto significa que las aplicaciones no pueden abrir otras aplicaciones a través del uso de iframes. Si la aplicación A crea un iframe con el src de la aplicación B, esto no abrirá la aplicación B en el iframe. Esto simplemente abrirá el sitio web qe se encuentra en esa URL. No usará ninguna de las cookies de B y por lo tanto no se comportará diferente si la aplicación B no estuviera instalada en el dispositivo.</p> -<p>Esto se aplica inclusive para las aplicaciones empaquetadas (más información acerca de estas abajo). inclusive si la aplicación A intenta abrir la aplicación enpaquetada B usando un iframe que apunte a app:// Dirección de la aplicación B, esto simplemente no podrá cargar. Si esto resulta en un error 404 o algún tipo de error determinado todavía falta deteminarse, pero definitivamente fallará al cargar. Y fallará de la misma manera no importa si la aplicación está instalada en el dispositivo o no, de modo que es imposible determinar para la aplicación A si la aplicación B se encuentra instalada.</p> -<p>Lo mismo sucede si el marco superior de la aplicación A es navegado por una URL a la aplicación B. Nosotros sabremos para un determinado marco que aplicación lo abrio, y por lo tanto cuando intente cargar la URL de la aplicación B en el marco de la aplicación A, esto sucederá exactamente como las dos situaciones descriptas arriba, por ejemplo, no hay forma de que use los recursos de B, como ser cookies u otra información local.</p> -<h3 id="Motivación"><span class="mw-headline" id="Motivation">Motivación</span></h3> -<p>Hay tanto beneficios como desventajas con este enfoque. La desventaja es que si un usuario interactúa con el mismo sitio web a través de diferentes aplicaciones, deberá registrarse en cada aplicación. Así tambien si un sitio web necesita almacenar información localmente, y el usuario interactúa con ese sitio en varias aplicaciones, la información terminará dplicada en cada aplicación, lo cual puede ser un problema si hay grandes cantidades de información.</p> -<p>El principal beneficio de de este enfoque es un modelo mucho más estable. No hay forma de que varias aplicaciones puedan hacerlo a través de sitios web de terceros en formas inesperadas que harían que instalar una aplicación haga que otra aplicación deje de funcionar. Cuando una aplicación es desinstalada, no hay forma que la información necesaria para otra aplicación se pierda, o que una aplicación deje de funcionar debido a una dependencia funcional con la aplicación desinstalada.</p> -<p>Un usuario puede instalar de forma segura la "Fabulosa Aplicación Social" para registrarse en Facebook sin tener que preocuparse que la aplicación "El Juego de DIbujos" pueda montar algún tipo de ataque para obtener la información del usuario de Facebook usando algún tipo de error o atajo que pueda existir en el sitio web de facebook.</p> -<p>También existen buenos beneficios para la privacidad. El usuario puede instalar de forma segura la "Aplicación de mi partido político" sin tener que preocuparse de que la "Apliación de empleados de la Megacorporación" sea capaz de detectar que aplicación se encuentra instalada o que información fue creada.</p> -<h3 id="Permisos_aislados">Permisos aislados</h3> -<p>Así como la información de un sitio web es aislada por medio de una sandbox, también son aislados los permisos otorgados. Si la aplicación A carga una página de <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> y la página pide utilizar la geolocalización y el usuario dice "permitir y recordar la decisión", esto solo significa que <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> tiene acceo a la geolocalización dentro de la aplicación A. Si la aplicación B abre <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, esa página no tendrá acceso a la geolocalización a menos que el usuario le garantice ese permiso de vuelta.</p> -<p>Y como en un navegador normal, los permisos se encuentran separados por origen. Si la aplicación A tiene el acceso garantizado para utilizar geolocalización, esto no significa que todos los origenes corriendo en la aplicación A tendrán ese permiso. Si la aplicación A abre un <iframe> a <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, entonces <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> tiene que pedir permiso antes que el acceso a la geolocalización sea garantizado.</p> -<h3 id="Sandbox_de_la_API_para_Navegadores">Sandbox de la API para Navegadores</h3> -<p>Para una seguridad adicional para aquellas aplicaciones que necesitan abrir una gran cantidad de URLs, como por ejemplo navegadores, añadimos el "browserContent flag" (indicador de contenido de navegador). El browserContent flag permite que cada aplicación tenga no una, sino dos sandbox, una para la aplicación en sí, y otra para cualquier contenido web que abra. Por ejemplo:</p> -<p>Digamos que la aplicación "Mi Navegador" carga desde el sitio <a class="external free" href="https://mybrowser.com" rel="nofollow">https://minavegador.com</a>. Este es el dominio de donde los scripts y otros recursos son cargados. Los scripts y recursos <em>pertenecen</em> a este dominio.</p> -<p>Ahora bien, si esta aplicación crea un <iframe mozbrowser>, un sandbox diferente es creado para este <iframe>, el cual será un sandbox diferente del usado por la aplicación - por ejemplo, si este oframe navega a <a class="external free" href="https://mybrowser.com" rel="nofollow">https://minavegador.com</a>, esto resultará en diferentes cookies usados dentro del <iframe mozbrowser>. Así también el contenido dentro del <iframe mozbrowser> verá diferentes IndexedDB y bases de datos localStorage de las que abrió la aplicación.</p> -<p>Esto también se aplica si "Mi Navegador" quiere crear integración con, por ejemplo, Google Maps para implementar navegación basada en to implementar navegación basada en la ubicación. Si la aplicación abre un <iframe> a <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, esto abrirá un iframe que recibirá las cookies para el sitio <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>. Si el usuario navega dentro del área de contenido web, por ejemplo del <iframe mozbrowser>, a <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, este usará cookies diferentes y permisos diferentes de los que existen a nivel de la aplicación.</p> -<p>Otro ejemplo donde esto sería util sería en una aplicación tipo Yelp. Yelp tiene la capacidad de visitar el website de un restaurante direntamente desde la aplicación. Al usar un <iframe mozbrowser> para abrir el sitio web de un restorante, la aplicación Yelp se asegura que el el sitio web no puede tener un <iframe> apuntando a la aplicación de Yelp (lo cual apuntaría a <a class="external free" href="http://yelp.com" rel="nofollow">http://yelp.com</a>). Si lo hiciera, el sitio web recibiría el sitio web de Yelp, en vez de la aplicación. Así no existe manera de que el sitio web pueda montar un ataque a la aplicación ya que el sitio web de Yelp no compartirá ninguno de los permisos o la información de la aplicación Yelp.</p> -<h2 id="Resumen_de_la_Seguridad_en_Aplicaciones">Resumen de la Seguridad en Aplicaciones</h2> -<p>La tabla de abajo resume los diferente tipos de aplicaciones de Firefox OS, y describe el formato, instalación, y el proceso de actualización de las Open Web Apps corriendo en Firefox OS.</p> -<table> - <caption> - Tipos de aplicaciones web</caption> - <thead> - <tr> - <th scope="col">Tipo</th> - <th scope="col">Entrega</th> - <th scope="col">Modelo de Permisos</th> - <th scope="col">Instalación</th> - <th scope="col">Actualizaciones</th> - </tr> - </thead> - <tbody> - <tr> - <td>Web</td> - <td>Alojada o empaquetada</td> - <td>Menos sensible a los permisos que no son peligrosos para exponer a contenido web sin validad</td> - <td>Instaladas desde cualquier lugar</td> - <td>Pueden ser actualizadas de forma transparente por el usuario o desde el marketplace, dependiendo de donde la aplicación fue instalada, y el mecanismo de entrega.</td> - </tr> - <tr> - <td>Privilegiada</td> - <td>Empaquetada y firmada</td> - <td>APIs privilegiadas que requieren de validación y autenticación de la aplicación</td> - <td>Instaladas desde un marketplace confiable</td> - <td>Actualizadas desde un marketplace confiable, al usuario se le pide aprovación para descargar e instalar las actualizaciones.</td> - </tr> - <tr> - <td>Certificada</td> - <td>Empaquetada</td> - <td>APIs poderosas y peligrosas que no se encuentran disponibles para aplicaciones de terceros.</td> - <td>Preinstaladas en el dispositivo</td> - <td>Actualizadas solo como parte de las actualizaciones a nivel del sistema.</td> - </tr> - </tbody> -</table> -<p><strong>Nota</strong>: Para la version 1.0 de Firefox OS, si bien las aplicaciones web pueden ser instaladas desde cualquier sitio web o marketplace, las aplicaciones privilegiadas solo pueden ser instaladas desde el Mozilla Marketplace, como el soporte a multiples marketplaces confiable no está todavía completo.</p> diff --git a/files/es/archive/b2g_os/security/index.html b/files/es/archive/b2g_os/security/index.html deleted file mode 100644 index e88430f481..0000000000 --- a/files/es/archive/b2g_os/security/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Firefox OS security -slug: Archive/B2G_OS/Security -tags: - - B2G - - Firefox OS - - Mobile - - Móvil - - Seguridad - - TopicStub - - movil(2) -translation_of: Archive/B2G_OS/Security ---- -<p>Los siguienes artículos cubren información sobre la seguridad de Firefox OS. Esto incluye caracerísticas generales de seguridad así como seguridad en las aplicaciones y mantener el proceso de instalación seguro.</p> - -<table class="topicpage-table"> - <tbody> - <tr> - <td> - <h2 class="Documentation" id="Documentation" name="Documentation">Documentación de seguridad de Firefox OS</h2> - - <dl> - <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">Modelo de seguridad de Firefox os</a></dt> - <dd>Un vistazo al manual de seguridad de Firefox OS</dd> - <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Security/System_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">Seguridad del sistema</a></dt> - <dd>Detalles de los controles de seguridad integrados en el <em>runtime</em> de Firefox OS</dd> - <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Seguridad de aplicaciones en Firefox OS</a></dt> - <dd>Un vistazo de cómo las aplicaciones son seguras en Firefox OS</dd> - <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications" title="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications">Instalación y actualización segura de aplicaciones</a></dt> - <dd>Cómo Firefox OS instala y acualiza las aplicaciones de forma segura.</dd> - <dt><a href="/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions" title="/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions">Permisos de Software en Firefox OS</a></dt> - <dd>Una guía de qué tipos de software tienen permisos para realizar varias tareas en Firefox OS.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Debugging_and_security_testing" title="/en-US/docs/Mozilla/Firefox_OS/Security/Debugging_and_security_testing#Marionette.3A_A_JavaScript_debugging_shell_for_Firefox_OS"><span style="display: none;"> </span>Depuración y pruebas de seguridad con Firefox OS</a></dt> - <dd>Esta guía muestra los pasos básicos de las pruebas de seguridad, desde la apertura de abrir un depurador remoto de JavaScript hasta la creación de un proxy HTTP/S de intercepción contra una versión de escritorio de Firefox OS.</dd> - </dl> - - <p><span class="alllinks"><a href="/en-US/docs/tag/B2G" title="/en-US/docs/tag/B2G">Ver Todo...</a></span></p> - </td> - <td> - <h2 class="Community" id="Community" name="Community">Obtener ayuda de la Comunidad</h2> - - <p>Si estás trabajando con Firefox OS, o desarrollando aplicaciones que te gustaría ejecutar en dispositivos Firefox OS, ¡Hay recursos de la comunidad para ayudarte!</p> - - <ul> - <li>Consulta el foro del proyecto Boot to Gecko: <ul> - <li><a href="https://lists.mozilla.org/listinfo/dev-b2g"> como lista de correo</a></li> - - - <li><a href="http://groups.google.com/group/mozilla.dev.b2g"> como grupo de noticias</a></li> - <li><a href="http://groups.google.com/group/mozilla.dev.b2g/feeds"> como RSS</a></li> -</ul></li> - <li>Haz una pregunta en el canal IRC de Boot to Gecko: <a class="link-irc" href="irc://irc.mozilla.org/b2g" title="irc://irc.mozilla.org/b2g">#b2g</a></li> - </ul> - - <p><span class="alllinks"><a class="external" href="http://www.catb.org/~esr/faqs/smart-questions.html" title="http://www.catb.org/~esr/faqs/smart-questions.html">No te olvides de la <em>netiquette</em>...</a></span></p> - - - <h2 class="Related_Topics" id="Related_Topics" name="Related_Topics">Temas Relacionados</h2> - - <ul> - <li><a href="/en-US/docs/Mobile" title="en-US/docs/Mobile">Móvil</a></li> - <li><a href="/en-US/docs/Security" title="/en-US/docs/Security">Seguridad</a></li> - </ul> - </td> - </tr> - </tbody> -</table> - -<p> </p> - -<div id="cke_pastebin" style="position: absolute; top: 483px; width: 1px; height: 1px; overflow: hidden; left: -1000px;"><br> -Firefox OS</div> diff --git a/files/es/archive/b2g_os/security/modelo_seguridad/index.html b/files/es/archive/b2g_os/security/modelo_seguridad/index.html deleted file mode 100644 index 8c03acd89e..0000000000 --- a/files/es/archive/b2g_os/security/modelo_seguridad/index.html +++ /dev/null @@ -1,255 +0,0 @@ ---- -title: Introducción a la seguridad de Firefox OS -slug: Archive/B2G_OS/Security/modelo_seguridad -translation_of: Archive/B2G_OS/Security/Security_model ---- -<p>Este documento proporciona una visión general del marco de trabajo de seguridad del sistema operativo de Mozilla Firefox OS, que está diseñado para proteger los dispositivos móviles de las amenazas a la plataforma, aplicaciones y datos. En Firefox OS, Mozilla ha implementado un modelo exhaustivo, integrado y de múltiples capas de seguridad que ofrece una protección mejor frente a los riesgos de seguridad en los teléfonos móviles.</p> -<h1 id="Seguridad_de_la_plataforma">Seguridad de la plataforma</h1> -<p>Firefox OS en su plataforma utiliza un modelo de seguridad de varias capas que esta diseñado para reducir los riesgos de seguridad en todos los niveles. Contramedidas de primera línea se combinan con una estrategia de defensa en profundidad que proporciona protección completa contra amenazas.</p> -<h2 id="Arquitectura_de_la_seguridad">Arquitectura de la seguridad</h2> -<p>Firefox OS conecta las aplicaciones basadas en la web con el hardware subyacente. Se trata de una pila de tecnologías integradas que consiste en los siguientes niveles:</p> -<p><img alt="" src="https://mdn.mozillademos.org/files/5023/platform.png" style="width: 660px; height: 478px;"></p> -<p><strong>Mobile device</strong> es el teléfono móvil ejecutando Firefox OS. <strong>Gonk</strong> consiste en el kernel de Linux, las librerías del sistema, el firmware y los controladores del dispositivo. <strong>Gecko</strong> es la capa de tiempo de ejecución de aplicaciones que proporciona el marco de trabajo para la ejecución de aplicaciones, e implementa las API Web que se usan para acceder a las funciones del dispositivo móvil. <strong>Gaia</strong> es la colección de aplicaciones web que conforman la experiencia de usuario (aplicaciones que contienen desde HTML5, CSS, JavaScript, imágenes, medios, y así sucesivamente).</p> -<p><strong>Gecko</strong> es el portero que hace cumplir las políticas de seguridad diseñadas para proteger el dispositivo móvil de un mal uso. La Capa <strong>Gecko</strong> actúa como intermediario entre las aplicaciones web (en la capa <strong>Gaia</strong>) y el teléfono. <strong>Gonk</strong> le ofrece las características del hardware del teléfono móvil directamente a la capa <strong>Gecko</strong> . Las aplicaciones web acceden a las funcionalidades del teléfono móvil sólo a través de las API Web, y sólo si <strong>Gecko</strong> permite la petición de acceso, no hay accesos directos ni "puertas traseras" en el teléfono. <strong>Gecko</strong> aplica los permisos e impide el acceso a las solicitudes no autorizadas.</p> -<h2 id="Implementación_del_sistema_de_seguridad">Implementación del sistema de seguridad</h2> -<p>Firefox OS viene instalado en el teléfono inteligente. la imagen original del sistema es creada por un conocido, una fuente de confianza que por lo general es el OEM del dispositivo, el cuál es responsable de ensamblar, construir, probar y firmar digitalmente el paquete que se distribuye.</p> -<p>Las medidas de seguridad se utilizan en toda la pila de tecnologías. Los privilegios del sistema de archivos son impuestas por las listas del control de acceso de Linux`s (ACLs). Las aplicaciones del sistema se instalan en un volumen que es de solo lectura (excepto durante las actualizaciones, donde es temporalmente tienen lectura y escritura ). Sólo las áreas que contienen los datos de usuario son de lectura y escritura. Varios componentes del hardware del dispositivo tiene una función de protección que se aplican de forma predeterminada como la práctica estándar de la industria. Los fabricantes de Chipset, por ejemplo, emplean técnicas de endurecimiento para reducir las vulnerabilidades. El núcleo de la plataforma (Gecko and Gonk) se endurece para reforzar su defensa contra las amenazas potenciales, utilizándose en su caso las características de endurecimiento del compilador. Para más detalles ver <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security">Seguridad en tiempo de ejecución</a>.</p> -<h2 id="Actualizaciones_seguras_del_sistema">Actualizaciones seguras del sistema</h2> -<p>Las actualizaciones y parches a la plataforma Firefox OS se implementan usando un proceso seguro de Mozilla que asegura la integridad de la imagen del sistema en el teléfono móvil. La actualización es creada por un conocido, una fuente de confianza que por lo general es el OEM del dispositivo, el cuál es responsable de ensamblar, construir, probar y firmar digitalmente el paquete que se distribuye.</p> -<p>Las actualizaciones del sistema pueden incluir la totalidad o una parte de la pila de Firefox OS. Si cambios en <strong>Gonk </strong>son incluidos en la actualización, entonces FOTA (Firmware sobre el aire ) es el proceso de instalación utilizado. La actualización por FOTA puede incluir cualquier otra parte de la pila de Firefox OS, incluyendo la gestión del dispositivo(FOTA, firmware / drivers), gestión de la configuración(configuraciones de Firefox OS), actualizaciones de seguridad, <strong>Gaia</strong>, <strong>Gecko </strong>y otros parches.</p> -<p>Actualizaciones que no involucren a <strong>Gonk</strong> pueden hacerse usando la utilidad de actualización de sistemas de Mozilla. Firefox OS utiliza el mismo marco de trabajo de actualizaciones, los procesos y el formato de archivos de Mozilla (MAR) (usado para actualizar los paquetes) como el producto Firefox para Escritorio. Para más información, consulte <a href="https://wiki.mozilla.org/Software_Update">https://wiki.mozilla.org/Software_Update</a>.</p> -<p>Al integrar el servicio de actualización que puede ser proporcionado por el fabricante, en el teléfono móvil comprueba periódicamente si hay actualizaciones del sistema. Una vez que un paquete del sistema esta disponible y es detectado por el servicio de actualizaciones, se solicita al usuario que confirme la actualización. Antes de instalar las actualizaciones en dispositivo móvil, se comprueba que haya suficiente espacio para aplicar la actualización y la distribución se verifica para:</p> -<ul> - <li>Origen de las actualizaciones (verifica la ubicación de la fuente (protocolo:dominio:puerto) de la actualización del sistema y el manifiesto)</li> - <li>Integridad del archivo (SHA-256 verificación del hash)</li> - <li>Firma del código (ver certificado contra una raíz de confianza)</li> -</ul> -<p>Las siguientes medidas de seguridad son utilizadas durante el proceso de actualización:</p> -<ul> - <li>Mozilla recomienda y espera que las actualizaciones sean a través de una conexión SSL.</li> - <li>Se requiere una fuerte verificación de criptografía antes de instalar un paquete de firmware.</li> - <li>La actualización completa debe ser descargada en una ubicación específica y segura antes de que comience el proceso de actualización.</li> - <li>El sistema debe estar en un estado seguro cuando se inicia el proceso de actualización, sin aplicaciones web en ejecución.</li> - <li>Las claves deben ser almacenadas en una ubicación segura en el dispositivo.</li> -</ul> -<p>Rigurosas comprobaciones se llevan a cabo para asegurar que la actualización es aplicada correctamente en teléfono móvil.</p> -<h1 id="Seguridad_en_aplicaciones">Seguridad en aplicaciones</h1> -<p>Firefox OS utiliza una estrategia de seguridad de tipo defensa en profundidad apara proteger el teléfono móvil de las aplicaciones intrusivas o maliciosos. Esta estrategia cuenta con una variedad de mecanismos, incluyendo los niveles de permisos implícitos basados en un modelo de aplicaciones de confianza, la ejecución de recinto de seguridad en tiempo de ejecución, únicamente acceso al hardware subyacente teléfono móvil a través del API, un modelo de permisos robusto y seguridad en la instalación y los procesos de actualización. Para obtener información técnica, consulte: <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Seguridad de las aplicaciones.</a></p> -<p>En Firefox OS, todas las aplicaciones son aplicaciones web - programas escritos utilizando HTML5, JavaScript, CSS, media y otras tecnologías web abiertas (las páginas que se ejecutan en el navegador no se conocen como aplicaciones Web en este contexto). Porque no hay binario ("nativo") las aplicaciones instaladas por el usuario, todo acceso al sistema está mediada estrictamente a través de las API Web. Incluso el acceso al sistema de archivos es sólo a través de las API de Web y una base de datos SQLite de fondo - no hay acceso directo desde las aplicaciones a los archivos almacenados en la tarjeta SD.</p> -<p>Firefox OS limita y hace cumplir el ámbito de los recursos que pueden ser accedidos o utilizados por una aplicación, mientras que también apoya una amplia gama de aplicaciones con diferentes niveles de permisos. Mozilla implementa controles estrictos sobre qué tipo de aplicaciones pueden acceder a qué APIs. Por ejemplo, sólo las aplicaciones certificadas (se suministran con el teléfono) pueden tener acceso a la API de telefonía. La aplicación Marcador tiene privilegios para acceder a la API de telefonía para hacer llamadas telefónicas, pero no todas las aplicaciones certificadas se puede acceder a esta API. Esto evita que un escenario, por ejemplo, en el que se instala una aplicación de terceros arbitraria, marca un número de teléfono de pago por uso (900 y 910), y por debajo te consume gran cantidad del saldo del teléfono celular. Sin embargo, otras aplicaciones OEM pueden darse de forma selectiva el acceso a la API de telefonía. Por ejemplo, un operador podría proporcionar una aplicación de gestión de sistemas que permite a los clientes administrar su cuenta, incluyendo la posibilidad de llamar a la facturación del operador o de la oficina de apoyo directamente.</p> -<h2 id="Aplicaciones_confiables_y_no_confiables">Aplicaciones confiables y no confiables</h2> -<p>Firefox OS clasifica las aplicaciones de acuerdo a los siguientes tipos:</p> -<table> - <thead> - <tr> - <th style="width: 82px;"> - <p>Tipo</p> - </th> - <th style="width: 102px;"> - <p>Nivel de confianza</p> - </th> - <th style="width: 447px;"> - <p>Descripción</p> - </th> - </tr> - </thead> - <tbody> - <tr> - <td style="width: 82px;"> - <p>Certificadas</p> - </td> - <td style="width: 102px;"> - <p>Altamente confiable</p> - </td> - <td style="width: 447px;"> - <p>Aplicaciones del sistema que han sido aprobadas por el operador o el OEM (debido al riesgo de corrupción para el dispositivo o riesgo para las funcionalidades críticas). Aplicaciones y servicios del sistema solamente, no destinadas a aplicaciones de terceros.<br> - Esta designación se reserva para sólo un pequeño número de aplicaciones críticas. Ejemplos: SMS, Bluetooth, cámara, reloj del sistema, la telefonía y el marcador por defecto (para garantizar que los servicios de emergencia siempre están accesibles).</p> - </td> - </tr> - <tr> - <td style="width: 82px;"> - <p>Privilegiadas</p> - </td> - <td style="width: 102px;"> - <p>Confiables</p> - </td> - <td style="width: 447px;"> - <p>Aplicaciones de terceros que han sido revisados, aprobados y firmados digitalmente por un mercado autorizado.</p> - </td> - </tr> - <tr> - <td style="width: 82px;"> - <p>Web (todo lo demás)</p> - </td> - <td style="width: 102px;"> - <p>No confiables</p> - </td> - <td style="width: 447px;"> - <p>Contenido web regular. Incluye tanto las aplicaciones instaladas (almacenadas en el teléfono móvil) y las aplicaciones de servidor (almacenados remotamente, con sólo un archivo de manifiesto de aplicación almacenada en el teléfono móvil). El manifiesto para aplicaciones de servidor se puede obtener a través de un mercado de aplicaciones.</p> - </td> - </tr> - </tbody> -</table> -<p>El nivel de confianza de una aplicación determina, en parte, su capacidad para acceder a la funcionalidades en el teléfono móvil.</p> -<ul> - <li>Las aplicaciones certificadas tienen permiso para la mayoría de operaciones de la API Web</li> - <li>Las aplicaciones privilegiadas tienen permisos a un subconjunto de las operaciones de la API Web accesibles para las aplicaciones certificadas.</li> - <li>Las aplicaciones no confiables tienen permisos para un subconjunto de las operaciones de la API Web accesibles para las aplicaciones con privilegios. Estas son sólo las APIs Web que contiene suficientes medidas de mitigación de seguridad para estar expuesta a contenido web que no se confía.</li> -</ul> -<p>Algunas operaciones, como el acceso a la red, se supone de un permiso implícito para todas las aplicaciones. En general, cuanto más sensible es la operación (por ejemplo, marcar un número de teléfono o el acceso a la lista de contactos), mayor es el nivel de confianza requerido en la aplicación para ejecutarla.</p> -<h3 id="Principle_of_Least_Permissions">Principle of Least Permissions</h3> -<p>For web apps, the Firefox OS security framework follows the <em>principle of least permissions</em>: start with the absolute minimum permissions, then selectively grant additional privileges only when required and reasonable. By default, an app starts with very low permissions, which is comparable to untrusted web content. If the app makes Web API calls that require additional permissions, it must enumerate these additional permissions in its <em>manifest</em> (described later in this document). Gecko will consider granting Web API access to an application only if the applicable privileges are explicitly requested in its manifest. Gecko will grant the requested permission only if the <em>type </em>of the Web App (certified, trusted, or web) is sufficiently qualified for access.</p> -<h3 id="Review_Process_for_Privileged_Apps_in_the_Marketplace">Review Process for Privileged Apps in the Marketplace</h3> -<p>In order for an app to become privileged, the app provider must submit it for consideration to an authorized Marketplace. The Marketplace subjects the app to a rigorous code review process: verifying its authenticity and integrity, ensuring that requested permissions are used for the purposes stated (in the permission rationale), verifying that the use of implicit permissions is appropriate, and validating that any interfaces between privileged app content and unprivileged external content have the appropriate mitigations to prevent elevation of privilege attacks. The Marketplace has the responsibility to ensure that the web app will not behave maliciously with the permissions that it is granted.</p> -<p>After an app passes this review, it is approved for use, its app manifest is digitally signed by the Marketplace, and it is made available for mobile users to download. The signature ensures that, if the web store were somehow hacked, the hacker could not get away with installing arbitrary content or malicious code on users’ phones. Due to this vetting process, Firefox OS gives privileged apps obtained from a Marketplace a higher degree of trust than everyday (untrusted) web content.</p> -<h2 id="Packaged_and_Hosted_Apps">Packaged and Hosted Apps</h2> -<p>Apps for Firefox OS can be either <em>packaged</em> (stored on the mobile phone) or <em>hosted</em> (stored on a remote web server, with just a manifest stored on the mobile phone). There are some differences in the way in which security is managed for each. Nonetheless, packaged and hosted apps are both subject to application sandboxing, which is described later in this document.</p> -<h3 id="Packaged_Apps">Packaged Apps</h3> -<p>A packaged app consists of a ZIP file containing application resources (HTML5, CSS, JavaScript, images, media), as well as a manifest that provides an explicit list of assets and their corresponding hashes. Certified and privileged apps must be packaged apps because the app manifest needs to be digitally signed. When a user obtains a packaged app, the ZIP file is downloaded onto the mobile phone, and the manifest is read from a known location inside the ZIP file. During the install process, app assets are verified and remain stored locally in the package. All explicit permissions are requested at runtime, showing the user the app's data usage intentions, and persisted by default.</p> -<p>To refer to app resources in a packaged app, the URL begins with app: using the following format:</p> -<p><code>app://<em>identifier</em>/<em>path_within_zipfile</em>/file.html</code></p> -<p>where app:// represents the mount point for the ZIP file, and <em>identifier</em> is a UUID that is generated when the app is installed on the mobile phone. This mechanism ensures that resources referred to with an app: URL are contained in the ZIP file. The path within an app: is relative, so relative links to resources in the ZIP file are allowed.</p> -<p>While packaged apps are primarily intended to be used for Certified or Privileged apps, regular web apps can also be packaged. However, they do not gain any increase in trust or permissions access simply because they are packaged.</p> -<h3 id="Hosted_Apps">Hosted Apps</h3> -<p>Hosted apps are located on a web server and loaded via HTTP. Only the app manifest is stored on the mobile phone. Everything else is stored remotely. Certain APIs are available only to privileged and certified apps, which requires the app to be packaged due to signing requirements. Therefore, a hosted app will not have access to any of the Web APIs operations that require privileged or certified app status.</p> -<p>From a security point of view, hosted apps work very much like normal websites. A hosted app is loaded by invoking a hard-coded, fully-qualified URL that points to the startup page in the root directory of the app on that web server. Once a hosted app is loaded, the mobile phone links to pages using the same URLs that are used when browsing the web site.</p> -<h2 id="App_Manifest">App Manifest</h2> -<p>An Open Web App manifest contains information that a Web browser needs in order to interact with an app. A manifest is a JSON file with (at a minimum) a name and description for the app. For further details, refer to <a href="/en-US/docs/Apps/FAQs/About_app_manifests" title="/en-US/docs/Apps/FAQs/About_app_manifests">FAQs about app manifests</a>.</p> -<h3 id="Example_Manifest">Example Manifest</h3> -<p>The following code listing shows an example manifest with just basic settings:</p> -<pre class="brush:text">{ - "name": "My App", - "description": "My elevator pitch goes here", - "launch_path": "/", - "icons": { - "128": "/img/icon-128.png" - }, - "developer": { - "name": "Your name or organization", - "url": "http://your-homepage-here.org" - }, - "default_locale": "en" -}</pre> -<h3 id="Security_Settings_in_the_App_Manifest">Security Settings in the App Manifest</h3> -<p>The manifest can also contain other settings, including the following security settings:</p> -<table> - <thead> - <tr> - <th style="width: 152px;"> - <p>Field</p> - </th> - <th style="width: 479px;"> - <p>Description</p> - </th> - </tr> - </thead> - <tbody> - <tr> - <td style="width: 152px;"> - <p>permissions</p> - </td> - <td style="width: 479px;"> - <p>Permissions required by the app. An app must list every Web API it intends to use that requires user permission. Most permissions make sense for privileged apps or certified apps, but not for hosted apps. Properties per API:</p> - <ul> - <li><strong>description</strong> - A string specifying the intent behind requesting use of this API. Required.</li> - <li><strong>access</strong> - A string specifying the type of access required for the permission. Implicit permissions are granted at install time. Required for only a few APIs. Accepted values: <strong>read</strong>, <strong>readwrite</strong>, <strong>readcreate</strong>, and <strong>createonly</strong>.</li> - </ul> - </td> - </tr> - <tr> - <td style="width: 152px;"> - <p>installs_allowed_from</p> - </td> - <td style="width: 479px;"> - <p>Origin of the app. Array of origins (scheme+unique hostname) that are allowed to trigger installation of this app. Allows app providers to restrict installs from only an authorized Marketplace (such as <a href="https://marketplace.firefox.com/">https://marketplace.firefox.com/</a>).</p> - </td> - </tr> - <tr> - <td style="width: 152px;"> - <p>csp</p> - </td> - <td style="width: 479px;"> - <p>Content Security Policy (CSP). Applied to all pages loaded in the app. Used to harden the app against bugs that would allow an attacker to inject code into the app. If unspecified, privileged and certified apps have system-defined defaults. Syntax:<br> - <a href="https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp">https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp</a></p> - <p><em>Note that this directive can only increase the CSP applied. You cannot use it, for example, to reduce the CSP applied to a privileged App.</em></p> - </td> - </tr> - <tr> - <td style="width: 152px;"> - <p>type</p> - </td> - <td style="width: 479px;"> - <p>Type of application (web, privileged, or certified).</p> - </td> - </tr> - </tbody> -</table> -<p>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.</p> -<h2 id="Sandboxed_Execution">Sandboxed Execution</h2> -<p>This section describes application and execution sandboxes.</p> -<h3 id="Application_Sandbox">Application Sandbox</h3> -<p>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). For details, see <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model</a>.</p> -<p>The following figure provides an overview of this security model.</p> -<p><img alt="" src="https://mdn.mozillademos.org/files/5025/sandbox.png"></p> -<p>By isolating each app, its impact is contained within its own worker space. It cannot interfere with anything (such as other apps or their data) outside of that worker space.</p> -<h3 id="Execution_Sandbox">Execution Sandbox</h3> -<p>B2G (Gecko) runs in a highly-privileged system process that has access to hardware features in the mobile phone. At run-time, 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.</p> -<p>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 a listener process detects an event generated by some other process), and is mediated through the B2G process.</p> -<h3 id="Hardware_Access_Only_via_the_Web_API">Hardware Access Only via the Web API</h3> -<p>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.</p> -<h1 id="Security_Infrastructure">Security Infrastructure</h1> -<p>The following figure shows the components of this security framework:</p> -<p><img alt="" src="https://mdn.mozillademos.org/files/5027/securityframework.png" style="width: 979px; height: 591px;"></p> -<ul> - <li><strong>Permission Manager</strong>: Gateway to accessing functionality in the Web API, which is the only access to the underlying hardware.</li> - <li><strong>Access Control List</strong>: Matrix of roles and permissions required to access Web API functionality.</li> - <li><strong>Credential Validation</strong>: Authentication of apps/users.</li> - <li><strong>Permissions Store</strong>: Set of privileges required to access Web API functionality.</li> -</ul> -<h2 id="Permissions_Management_and_Enforcement">Permissions Management and Enforcement</h2> -<p>Firefox OS security is designed to verify and enforce the permissions granted to web apps.<br> - 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).</p> -<p>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:</p> -<ul> - <li>permissions associated with calling app (as specified in the manifest and based on the app type)</li> - <li>permissions required to execute the requested operation (Web API call)</li> -</ul> -<p>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.</p> -<h2 id="Prompting_Users_for_Permission">Prompting Users for Permission</h2> -<p>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 these operations, web apps are required to specify, in their manifest, their justification for requiring this permission. This <em>data usage intention</em> 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.</p> -<h2 id="Secure_App_Update_Process">Secure App Update Process</h2> -<p><img alt="" src="https://mdn.mozillademos.org/files/5029/updateprocess.png" style="width: 979px; height: 102px;"></p> -<p>For app upgrades and patches to a <em>privileged</em> 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:</p> -<ul> - <li>update origin (verify the source location protocol:domain:port of the update and manifest)</li> - <li>file integrity (SHA-256 hash check)</li> - <li>code signature (certificate check against a trusted root)</li> -</ul> -<p>Rigorous checks are in place to ensure that the update is applied properly to the mobile phone.<br> - 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.</p> -<h1 id="Device_Security_(Hardware)">Device Security (Hardware)</h1> -<p>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 the OEM for details. Firefox OS does allow users to configure passcodes and timeout screens, which are described in the next section.</p> -<h1 id="Data_Security">Data Security</h1> -<p>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.</p> -<h2 id="Passcode_and_Timeout_Screens">Passcode and Timeout Screens</h2> -<p>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.</p> -<h2 id="Sandboxed_Data">Sandboxed Data</h2> -<p>As described earlier, apps are sandboxed at run time. This prevents apps from accessing data that belongs to other apps <em>unless</em> that data is explicitly shared, and the app has sufficient permissions to access it.</p> -<h2 id="Serialized_Data">Serialized Data</h2> -<p>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 a 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.</p> -<h2 id="Data_Destruction">Data Destruction</h2> -<p>When a user uninstalls an app, all of the data (cookies, localStorage, Indexeddb, and so on) associated with that application is deleted.</p> -<h2 id="Privacy">Privacy</h2> -<p>Mozilla is committed to protecting user privacy and user data according to its privacy principles (<a href="https://www.mozilla.org/privacy/">https://www.mozilla.org/privacy/</a>), which stem from the Mozilla Manifesto (<a href="https://www.mozilla.org/about/manifesto.html">https://www.mozilla.org/about/manifesto.html</a>). 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:</p> -<ul> - <li><a href="http://www.mozilla.org/en-US/legal/privacy/firefox.html">http://www.mozilla.org/en-US/legal/privacy/firefox.html</a></li> - <li><a href="https://blog.mozilla.org/privacy/">https://blog.mozilla.org/privacy/</a></li> - <li><a href="http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones">http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones</a></li> -</ul> -<p>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:</p> -<ul> - <li>Do Not Track option</li> - <li>ability to disable Firefox browser cookies</li> - <li>ability to delete the Firefox OS browsing history</li> -</ul> -<p> </p> |