OLPC Bitfrost/lang-es: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (→‎Daniar la maquina: first draft)
m (Reverted edits by 201.6.3.241 (Talk) to last version by 201.221.39.218)
 
(54 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{OLPC}}
{{Translation | lang = es | source = OLPC Bitfrost | version = 40533}}
{{Ongoing Translation}}
<!-- áéíóú ü ñÑ¡¿©® -->
<!-- áéíóú ü ñÑ¡¿©® -->
<big>
<font size="6">
Sistema de seguridad en la laptop XO de la OLPC
'''Seguridad de la laptop XO de la OLPC'''


La plataforma de seguridad Bitfrost
'''Plataforma de seguridad Bitfrost'''
</font>
</big>
{{ Translated text |
<big>System security on the One Laptop per Child's XO laptop


The Bitfrost security platform</big>
1 System security on the One Laptop per Child's XO laptop
| display = none }}
2 The Bitfrost security platform

3 =======================================================
{{anchor|Chapter 0}}{{anchor|Introduction}}
4
5 :Author
6 Ivan Krstić
7 ivan AT laptop.org
8 One Laptop Per Child
9 http://laptop.org
10
11 :Acknowledgments
12 Simson Garfinkel, a security consultant for OLPC, contributed to this
13 document. This document also builds upon a growing body known as
14 "HCI-SEC," the application of recent advances in the field of Human
15 Computer Interaction to the important goals of computer security. More
16 information about HCI-SEC can be found in the book "Security and
17 Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in
18 Garfinkel's PhD thesis, "Design Principles and Patterns for Computer
19 Systems that are Simultaneously Secure and Usable" (MIT, 2005).
20
21 We acknowledge also a panel of reviewers that prefer to stay anonymous, who
22 provided insightful comments and feedback on previous drafts of this
23 document.
24
25 :Metadata
26 Revision: Draft-19 - release 1
27 Timestamp: Wed Feb 7 00:50:57 UTC 2007
28 Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
29 Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost
30
31 We welcome feedback on this document, preferably to the public OLPC
32 security mailing list, for which you can sign up at the feedback URL given
33 above. If you strongly prefer to keep your comments private, you may mail
34 the author of the document at the provided e-mail address.
35
36 This is NOT the final version of the specification. The contents of this
37 document accurately reflect OLPC's thinking about security at the time of
38 writing, but certain aspects of the security model may change before
39 production. This document will be updated to reflect any such changes. The
40 latest version of this document may be found at the authoritative version
41 URL.
42
43
44
45
= Introducción =
= Introducción =

46 0. Introduction
{{anchor|Chapter 0.1}}{{anchor|Foreword}}
47 ===============
48
== Prefacio ==
== Prefacio ==

49 0.1. Foreword
50 -------------
51
En 1971, los programadores Ken Thompson y Dennis Ritchie de AT&T produjeron la primera versión de UNIX. El sistema operativo, que comenzó en 1969 como un proyecto no-pago llamado UNICS, fue renombrado y financiado por Bell Labs cuando los programadores ofrecieron agregarle soporte para el procesamiento de texto. Muchas de esas ideas centrales detrás de Unix aún persisten hoy en día: los populares sistemas operativos para servidores como Linux, FreeBSD, y muchos otros comparten mucho del diseño básico de UNIX.
En 1971, los programadores Ken Thompson y Dennis Ritchie de AT&T produjeron la primera versión de UNIX. El sistema operativo, que comenzó en 1969 como un proyecto no-pago llamado UNICS, fue renombrado y financiado por Bell Labs cuando los programadores ofrecieron agregarle soporte para el procesamiento de texto. Muchas de esas ideas centrales detrás de Unix aún persisten hoy en día: los populares sistemas operativos para servidores como Linux, FreeBSD, y muchos otros comparten mucho del diseño básico de UNIX.
<!-- áéíóú ü ñÑ¡¿©® -->
52 In 1971, 35 years ago, AT&T programmers Ken Thompson and Dennis Ritchie
53 released the first version of UNIX. The operating system, which started in 1969
54 as an unpaid project called UNICS, got a name change and some official funding
55 by Bell Labs when the programmers offered to add text processing support. Many
56 of the big design ideas behind UNIX persist to this day: popular server
57 operating systems like Linux, FreeBSD, and a host of others all share much of
58 the basic UNIX design.
59
La versión de UNIX de 1971 soportaba los siguientes permisos de seguridad en los archivos de usuarios:


La versión de UNIX de 1971 soportaba los siguientes permisos de seguridad en los archivos de usuarios:
* no-dueño puede cambiar el archivo (escritura)
* no-dueño puede cambiar el archivo (escritura)
* no-dueño puede leer el archivo
* no-dueño puede leer el archivo
Line 77: Line 29:
* el archivo puede ser ejecutado
* el archivo puede ser ejecutado
* el archivo es set-uid
* el archivo es set-uid
{{ Translated text |
60 The 1971 version of UNIX supported the following security permissions on
In 1971, 35 years ago, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.
61 user files:

62
The 1971 version of UNIX supported the following security permissions on user files:
63 * non-owner can change file (write)
64 * non-owner can read file
* non-owner can change file (write)
65 * owner can change file (write)
* non-owner can read file
66 * owner can read file
* owner can change file (write)
67 * file can be executed
* owner can read file
68 * file is set-uid
* file can be executed
* file is set-uid
69
| display = block }}

Estos permisos deben parecerles familiares, ya que son muy similares a los permisos de seguridad que un usuario puede darle a sus archivos hoy en día, en su sistema operativo de elección. Lo que es preocupante&mdash;casi increíble&mdash;acerca de estos permisos es que han permanecido virtualmente como el ''único'' mecanismo de control real que un usuario tiene sobre sus documentos personales actualmente: un usuario puede elegir proteger sus archivos de otras personas en el sistema, pero no tiene ningún control sobre lo que sus programas pueden hacer sobre sus archivos.
Estos permisos deben parecerles familiares, ya que son muy similares a los permisos de seguridad que un usuario puede darle a sus archivos hoy en día, en su sistema operativo de elección. Lo que es preocupante&mdash;casi increíble&mdash;acerca de estos permisos es que han permanecido virtualmente como el ''único'' mecanismo de control real que un usuario tiene sobre sus documentos personales actualmente: un usuario puede elegir proteger sus archivos de otras personas en el sistema, pero no tiene ningún control sobre lo que sus programas pueden hacer sobre sus archivos.

70 These permissions should look familiar, because they are very close to the same
71 security permissions a user can set for her files today, in her operating
72 system of choice. What's deeply troubling -- almost unbelievable -- about these
73 permissions is that they've remained virtually the _only_ real control
74 mechanism that a user has over her personal documents today: a user can choose
75 to protect her files from other people on the system, but has no control
76 whatsoever over what her own programs are able to do with her files.
77
En 1971, esto podía ser aceptable: fue 20 años antes del arribo de la Web, y los riesgos para la mayoria de los usuarios era totalmente diferente al que se aplica hoy en día. Pero entonces, como es que nos sorprendemos al no poder detener los virus y ''malware'', cuando nuestras defensas han permanecido básicamente las mismas desde hace 35 años?
En 1971, esto podía ser aceptable: fue 20 años antes del arribo de la Web, y los riesgos para la mayoria de los usuarios era totalmente diferente al que se aplica hoy en día. Pero entonces, como es que nos sorprendemos al no poder detener los virus y ''malware'', cuando nuestras defensas han permanecido básicamente las mismas desde hace 35 años?
{{ Translated text |
78 In 1971, this might have been acceptable: it was 20 years before the advent of
These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling -- almost unbelievable -- about these permissions is that they've remained virtually the _only_ real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.
79 the Web, and the threat model for most computer users was entirely different

80 than the one that applies today. But how, then, is it a surprise that we can't
81 stop viruses and malware now, when our defenses have remained largely unchanged
In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?
| display = block }}
82 from thirty-five years ago?

83
El núcleo del problema radica en el supuesto que cualquier programa ejecutándose en el sistema a cuenta de un usuario debería tener las mismas habilidades y permisos que cualquier otro programa ejecutándose en el sistema a cuenta del mismo usuario. 1971 fue siete años antes que la primera red internacional (basada en ''packet-switch'') existiese. Y la primera red de área amplia (''wan - wide area network'') usando TCP/IP, el estándar de la actual Internet, no fue creada sino hasta 1983, doce años después que Thompson y Ritchie diseñaran los permisos de archivos que ahora discutimos. En resumidas cuentas, en 1971 casi no existía la posibilidad que un programa "existiera" en una computadora excepto si el dueño de la cuenta&mdash;el usuario&mdash;lo transportaba físicamente a una máquina (por ejemplo, en cinta perforada), o lo ingresase manualmente. Y por ende, la aproximación a la seguridad del "todo o nada", donde los programas ejecutándose tienen el control total sobre la cuenta de su dueño, tenían sentido: cualquier código que el usuario ejecutáse, gozaba de su confianza ipso-facto en términos prácticos.
El corazón del problema radica en el supuesto que cualquier programa ejecutándose en el sistema a cuenta de un usuario debería tener las mismas habilidades y permisos que cualquier otro programa ejecutándose en el sistema a cuenta del mismo usuario. 1971 fue siete años antes que la primera red internacional (basada en ''packet-switch'') existiese. Y la primera red de área amplia (''wan - wide area network'') usando TCP/IP, el estándar de la actual Internet, no fue creada sino hasta 1983, doce años después que Thompson y Ritchie diseñaran los permisos de archivos que ahora discutimos. En resumidas cuentas, en 1971 casi no existía la posibilidad que un programa "existiera" en una computadora excepto si el dueño de la cuenta&mdash;el usuario&mdash;lo transportaba físicamente a una máquina (por ejemplo, en cinta perforada), o lo ingresase manualmente. Y por ende, la aproximación a la seguridad del "todo o nada", donde los programas ejecutándose tienen el control total sobre la cuenta de su dueño, tenían sentido: cualquier código que el usuario ejecutáse, gozaba de su confianza ipso-facto en términos prácticos.
{{ Translated text |
84 The crux of the problem lies in the assumption that any program executing on
The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner -- the user -- physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.
85 a system on the user's behalf should have the exact same abilities and
| display = block }}
86 permissions as any other program executing on behalf of the same user. 1971 was

87 seven years before the first ever international packet-switched network came
88 into existence. And the first wide-area network using TCP/IP, the communication
89 suite used by the modern Internet, wasn't created until 1983, twelve years
90 after Thompson and Ritchie designed the file permissions we're discussing. The
91 bottom line is that in 1971, there was almost no conceivable way a program
92 could "come to exist" on a computer except if the account owner -- the user --
93 physically transported it to a machine (for instance, on punched tape), or
94 entered it there manually. And so the "all or nothing" security approach, where
95 executing programs have full control over their owner's account, made quite a
96 lot of sense: any code the user executed, she ipso facto trusted for all
97 practical purposes.
98
Avancemos en el tiempo a la actualidad, y la situación no podría ser más diferente: el contraste máximo es quizás la Web, donde el navegador (''browser'') ejecuta código foráneo en prácticamente todas la páginas visitadas! Los navegadores utilizan mecanismos de ''areneros'' (''sandbox'') cada vez más complejos con la intención de restringir las capacidades para dicho código foráneo (''scripts''), pero aún los navegadores más modernos están corrigiendo errores en ellos. Y no nos olvidemos del e-mail: cualquiera puede enviarle a un usuario un programa ejecutable, y por muchos años, la reacción casi instintiva era abrirlo y ejecutarlo. El código foráneo no digno de confianza a priori se encuentra por todos lados, y la única defensa pareciera ser un tedioso entrenamiento del usuario y el software anti-virus&mdash;suponiendo que este último esté actualizado, y que sus fabricantes hayan tenido el tiempo suficiente para desconstruir cada virus nuevo y construir su correspondiente defensa.
Avancemos en el tiempo a la actualidad, y la situación no podría ser más diferente: el contraste máximo es quizás la Web, donde el navegador (''browser'') ejecuta código foráneo en prácticamente todas la páginas visitadas! Los navegadores utilizan mecanismos de ''areneros'' (''sandbox'') cada vez más complejos con la intención de restringir las capacidades para dicho código foráneo (''scripts''), pero aún los navegadores más modernos están corrigiendo errores en ellos. Y no nos olvidemos del e-mail: cualquiera puede enviarle a un usuario un programa ejecutable, y por muchos años, la reacción casi instintiva era abrirlo y ejecutarlo. El código foráneo no digno de confianza a priori se encuentra por todos lados, y la única defensa pareciera ser un tedioso entrenamiento del usuario y el software anti-virus&mdash;suponiendo que este último esté actualizado, y que sus fabricantes hayan tenido el tiempo suficiente para desconstruir cada virus nuevo y construir su correspondiente defensa.
{{ Translated text |
99 Fast forward to today, and the situation couldn't be more different: the
Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and antivirus software -- the latter assuming it's fully updated, and assuming the antivirus makers have had time to deconstruct each latest virus and construct a defense for it.
100 starkest contrast is perhaps the Web, where a user's web browser executes
| display = block }}
101 untrusted scripting code on just about every web page she visits! Browsers are

102 growing increasingly complex sandboxing systems that try to restrict the
La mayoría de las ideas y tecnologías que conforman la plataforma Bitfrost no son el resultado de nuevas investigaciones: han sido conocidas en la literatura pertinente durante años, algunas han sido probadas en situaciones reales, y otras en laboratorios. Lo que se destaca en la XO de la OLPC, es que representa la primera vez que estas medidas de seguridad han sido cuidadosamente ensambladas en un sistema a ser distribuido a decenas o centenas de millones de usuarios. Las laptops son probablemente la primvera vez que un producto de computación masiva ha decidido romper con su legado con tal de mejorar la seguridad. Por ejemplo, notarán que la discusión sobre anti-virus y ''anti-spyware'' no figura en la especificación de Bitfrost, principalmente porque la plataforma de seguridad torna dicho tema en algo irrelevante.
103 abilities of such web scripts, but even the latest browser versions are still
{{ Translated text |
104 fixing bugs in their scripting engine implementations. And don't forget e-mail:
Most technologies and approaches mentioned in the rest of this document do not represent original research: they have been known in the security literature for years, some of them have been deployed in the field, and others are being tested in the lab. What makes the OLPC XO laptops radically different is that they represent the first time that all these security measures have been carefully put together on a system slated to be introduced to tens or hundreds of millions of users. The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security. As an example, you'll find that talk about anti-virus and anti-spyware technology is conspicuously absent from this document, because the Bitfrost security platform on the XO laptops largely renders these issues moot.
105 anyone can send a user an executable program, and for many years the users'
| display = block }}
106 instinctive reaction was to open the attachment and run the program. Untrusted

107 code is everywhere, and the only defense seems to be tedious user training and
108 antivirus software -- the latter assuming it's fully updated, and assuming the
109 antivirus makers have had time to deconstruct each latest virus and construct a
110 defense for it.
111
La mayoría de las ideas y tecnologías que conforman la plataforma Bitfrost no son el resultado de nuevas investigaciones: han sido conocidas en la literatura pertinente durante años, algunas han sido probadas en situaciones reales, y otras en laboratorios. Lo que se destaca en la XO de la OLPC, es que representa la primera vez que estas medidas de seguridad han sido cuidadosamente ensambladas en un sistema a ser distribuido a decenas o centenas de millones de usuarios. Las laptops son probablemente la primvera vez que un producto de computación masiva ha decidido romper con su legado con tal de mejorar la seguridad. Por ejemplo, notarán que la discusión sobre anti-virus y ''anti-spyware'' no figura en la especificación de Bitfrost, principalmente porque la plataforma de seguridad torna dicho tema en algo irrelevante.
112 Most technologies and approaches mentioned in the rest of this document do not
113 represent original research: they have been known in the security literature
114 for years, some of them have been deployed in the field, and others are being
115 tested in the lab. What makes the OLPC XO laptops radically different is that
116 they represent the first time that all these security measures have been
117 carefully put together on a system slated to be introduced to tens or hundreds
118 of millions of users. The laptops are also possibly the first time that a
119 mainstream computing product has been willing to give up compatibility with
120 legacy programs in order to achieve strong security. As an example, you'll find
121 that talk about anti-virus and anti-spyware technology is conspicuously absent
122 from this document, because the Bitfrost security platform on the XO laptops
123 largely renders these issues moot.
124
Nos hemos puesto como objetivo crear un sistema que sea drásticamente más seguro y usable que cualquier otro sistema masivo actualmente en el mercado. Un resultado de la dedicación a la usabilidad es que sólo existe una protección provista por Bitfrost que requiere una respuesta del usuario, y aún entonces, es una sencilla pregunta por 'si o no' comprehensible aún por un chico pequeño. El resto de la seguridad es provista tras bambalinas. El llevar al límite los aspectos de usabilidad y seguridad no es fácil, y es importante destacar que no hemos intentado crear, y no creemos que lo hayamos hecho, un sistema "perfectamente seguro". La idea de seguridad perfecta en el mundo real es vana, y negamos todo tipo de insinuacion que lo hayamos logrado.
Nos hemos puesto como objetivo crear un sistema que sea drásticamente más seguro y usable que cualquier otro sistema masivo actualmente en el mercado. Un resultado de la dedicación a la usabilidad es que sólo existe una protección provista por Bitfrost que requiere una respuesta del usuario, y aún entonces, es una sencilla pregunta por 'si o no' comprehensible aún por un chico pequeño. El resto de la seguridad es provista tras bambalinas. El llevar al límite los aspectos de usabilidad y seguridad no es fácil, y es importante destacar que no hemos intentado crear, y no creemos que lo hayamos hecho, un sistema "perfectamente seguro". La idea de seguridad perfecta en el mundo real es vana, y negamos todo tipo de insinuacion que lo hayamos logrado.
{{ Translated text |
125 We have set out to create a system that is both drastically more secure and
We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and as we state in the concluding chapter of this document, we have neither tried to create, nor do we believe we have created, a "perfectly secure" system. Notions of perfect security are foolish, and we distance ourselves up front from any such claims.
126 provides drastically more usable security than any mainstream system currently
| display = block }}
127 on the market. One result of the dedication to usability is that there is only

128 one protection provided by the Bitfrost platform that requires user response,
{{anchor|Chapter 0.2}}{{anchor|Security and OLPC}}
129 and even then, it's a simple 'yes or no' question understandable even by young
130 children. The remainder of the security is provided behind the scenes. But
131 pushing the envelope on both security and usability is a tall order, and as we
132 state in the concluding chapter of this document, we have neither tried to
133 create, nor do we believe we have created, a "perfectly secure" system. Notions
134 of perfect security are foolish, and we distance ourselves up front from any
135 such claims.
136
137
138
== La Seguridad y la OLPC ==
== La Seguridad y la OLPC ==

139 0.2. Security and OLPC
140 ----------------------
141
En términos de seguridad, la laptop XO de la OLPC es un ambiente muy particular. Su intención es introducir a chicos pequeños a la computación, muchos en ambientes que no han sido expuestos previamente a la computación o la Internet.
En términos de seguridad, la laptop XO de la OLPC es un ambiente muy particular. Su intención es introducir a chicos pequeños a la computación, muchos en ambientes que no han sido expuestos previamente a la computación o la Internet.

142 In terms of security, the OLPC XO laptops are a highly unique environment. They
143 are slated to introduce computers to young children, many in environments that
144 have had no prior exposure to computing or the Internet.
145
Aún más, la OLPC no tiene como objetivo una distribución reducida donde podría intervenir rápidamente de existir algún problema de seguridad con las máquinas o su uso; en vez, una vez distribuídas, cambios importantes en el modelo de seguridad podrían ser considerados difíciles o imposibles.
Aún más, la OLPC no tiene como objetivo una distribución reducida donde podría intervenir rápidamente de existir algún problema de seguridad con las máquinas o su uso; en vez, una vez distribuídas, cambios importantes en el modelo de seguridad podrían ser considerados difíciles o imposibles.
{{ Translated text |
146 What's more, OLPC is not targeting small-scale local deployments where it could
In terms of security, the OLPC XO laptops are a highly unique environment. They are slated to introduce computers to young children, many in environments that have had no prior exposure to computing or the Internet.
147 easily intervene in the case of security problems with the machines or their

148 usage; instead, once the machines are released in the wild, drastic changes in
149 the security model should be considered difficult or impossible.
What's more, OLPC is not targeting small-scale local deployments where it could easily intervene in the case of security problems with the machines or their usage; instead, once the machines are released in the wild, drastic changes in the security model should be considered difficult or impossible.
| display = block }}
150

Existe suficiente experiencia en bloquear las máquinas de los usuarios, usualmente en ambientes empresariales o académicos. Pero la OLPC tienen un requisito que invalida la mayor parte del conocimiento común: la OLPC es, por diseño, luchando para ser una plataforma inherentemente maleable, permitiendo a los chicos modificar, adaptar, o "hackear", sus propias máquinas como a ellos les plazca.
Existe suficiente experiencia en bloquear las máquinas de los usuarios, usualmente en ambientes empresariales o académicos. Pero la OLPC tienen un requisito que invalida la mayor parte del conocimiento común: la OLPC es, por diseño, luchando para ser una plataforma inherentemente maleable, permitiendo a los chicos modificar, adaptar, o "hackear", sus propias máquinas como a ellos les plazca.

151 Plenty of experience exists in locking down user machines, often in corporate
152 or academic settings. But OLPC has a final constraint that invalidates most of
153 the current common wisdom: OLPC is, by design, striving to be an eminently
154 malleable platform, allowing the children to modify, customize, or "hack",
155 their own machines any way they see fit.
156
El resultado es que ninguna política de seguridad sobre la computadora puede satisfacer nuestros requerimientos. En su lugar, distribuiremos y activaremos una politica rigurosa de seguridad apropiada aún al más jóven de los usuarios, y que sea capaz de proveer la máxima seguridad disponible. Sin embargo, proveeremos una interfaz gráfica simple con tal que los usuarios interesados puedan deshabilitar cualquiera de las protecciones, permitiendo al usuario ajustar el nivel de seguridad acorde a su interes en ''hackear'' su máquina.
El resultado es que ninguna política de seguridad sobre la computadora puede satisfacer nuestros requerimientos. En su lugar, distribuiremos y activaremos una politica rigurosa de seguridad apropiada aún al más jóven de los usuarios, y que sea capaz de proveer la máxima seguridad disponible. Sin embargo, proveeremos una interfaz gráfica simple con tal que los usuarios interesados puedan deshabilitar cualquiera de las protecciones, permitiendo al usuario ajustar el nivel de seguridad acorde a su interes en ''hackear'' su máquina.
{{ Translated text |
157 As a result, no one security policy on the computer will satisfy our
Plenty of experience exists in locking down user machines, often in corporate or academic settings. But OLPC has a final constraint that invalidates most of the current common wisdom: OLPC is, by design, striving to be an eminently malleable platform, allowing the children to modify, customize, or "hack", their own machines any way they see fit.
158 requirements. Instead, we will ship and enable by default a stringent policy

159 that's appropriate even for the youngest user, and which delivers the strongest
As a result, no one security policy on the computer will satisfy our requirements. Instead, we will ship and enable by default a stringent policy that's appropriate even for the youngest user, and which delivers the strongest available protections. However, we will provide a simple graphical interface for interested users to disable any of these protections, allowing the user to tailor the security level to match her interest in hacking her machine.
160 available protections. However, we will provide a simple graphical interface
| display = block }}
161 for interested users to disable any of these protections, allowing the user to

162 tailor the security level to match her interest in hacking her machine.
163
Este modo nos permite ser extremadamente seguros por defecto, y proteger aún al usuario que no tiene ningún concepto de la seguridad digital. Al mismo tiempo, evita el interponerse en el camino del usuario cada vez más sofisticado, e interesado en aumentar sus habilidades con la máquina.
Este modo nos permite ser extremadamente seguros por defecto, y proteger aún al usuario que no tiene ningún concepto de la seguridad digital. Al mismo tiempo, evita el interponerse en el camino del usuario cada vez más sofisticado, e interesado en aumentar sus habilidades con la máquina.

164 This approach allows us to be highly secure by default, and protect even the
165 user who has no conception of digital security. At the same time, it avoids
166 getting in the way of any user who is becoming more sophisticated, and
167 interested in increasing her abilities on the machine.
168
Finalmente, y dado que suscribimos a las teorías de aprendizaje constructivistas, eventualmente queremos incitar a todos los chicos a progresar a un nivel de sofisticación mayor y así tomar mayores libertades con su máquina. Sin embargo, mientras exista el potencial de desastre (ej: tornar la máquina totalmente inoperable, o pérdida total de datos), dicho potencial es un gran obstáculo para el progreso. Y es por eso que además de focalizarse en la seguridad, nos enfocamos explícitamente en proveer mecanismos que logren la recuperación de un modo trivial y no intimidante, como podría ser la recuperación del sistema operativo de múltiples fuentes y copias de respaldo desde un servidor central.
Finalmente, y dado que suscribimos a las teorías de aprendizaje constructivistas, eventualmente queremos incitar a todos los chicos a progresar a un nivel de sofisticación mayor y así tomar mayores libertades con su máquina. Sin embargo, mientras exista el potencial de desastre (ej: tornar la máquina totalmente inoperable, o pérdida total de datos), dicho potencial es un gran obstáculo para el progreso. Y es por eso que además de focalizarse en la seguridad, nos enfocamos explícitamente en proveer mecanismos que logren la recuperación de un modo trivial y no intimidante, como podría ser la recuperación del sistema operativo de múltiples fuentes y copias de respaldo desde un servidor central.
{{ Translated text |
169 Finally, because we subscribe to constructionist learning theories, we want to
This approach allows us to be highly secure by default, and protect even the user who has no conception of digital security. At the same time, it avoids getting in the way of any user who is becoming more sophisticated, and interested in increasing her abilities on the machine.
170 encourage children to all eventually progress to this level of a more
171 sophisticated user who takes greater liberties with her machine. However, as
172 long as there exists potential for disaster (i.e. rendering a machine fully
173 inoperable, or incurring total data loss), this potential serves as a strong
174 deterrent to this progression. Because of this, in addition to focusing on
175 security by default, we are explicitly focusing on providing mechanisms for
176 trivial and unintimidating disaster recovery, such as operating system recovery
177 from multiple sources and data backup to a central server.
178
179
180


Finally, because we subscribe to constructionist learning theories, we want to encourage children to all eventually progress to this level of a more sophisticated user who takes greater liberties with her machine. However, as long as there exists potential for disaster (i.e. rendering a machine fully inoperable, or incurring total data loss), this potential serves as a strong deterrent to this progression. Because of this, in addition to focusing on security by default, we are explicitly focusing on providing mechanisms for trivial and unintimidating disaster recovery, such as operating system recovery from multiple sources and data backup to a central server.
| display = block }}

{{anchor|Chapter 0.3}}{{anchor|About this document}}
== Acerca de este documento ==
== Acerca de este documento ==

181 0.3. About this document
182 ------------------------
183
Este documento hace un seguimiento de la seguridad a lo largo del ciclo de vida de la laptop en si, comenzando cuando la laptop es producida en la fábrica, al momento en que llega la chico por primera vez, a lo largo del uso de la laptop por el chico, y finalmente el momento en que el chico se deshace o descarta la laptop. Todo esto es precedido por una breve sección sobre nuestras metas y principios, que sirven como fondo para algunas decisiones que han sido tomadas, y quizás no sean obvias si uno piensa sobre la seguridad en el contexto de una laptop o computadora de escritorio normal.
Este documento hace un seguimiento de la seguridad a lo largo del ciclo de vida de la laptop en si, comenzando cuando la laptop es producida en la fábrica, al momento en que llega la chico por primera vez, a lo largo del uso de la laptop por el chico, y finalmente el momento en que el chico se deshace o descarta la laptop. Todo esto es precedido por una breve sección sobre nuestras metas y principios, que sirven como fondo para algunas decisiones que han sido tomadas, y quizás no sean obvias si uno piensa sobre la seguridad en el contexto de una laptop o computadora de escritorio normal.

<font size="1">
184 This document follows security throughout the life-cycle of the laptop itself,
185 starting from the moment a laptop is produced in the factory, to the moment it
186 first reaches a child, throughout the child's use of the laptop, and finally
187 stopping at the moment a child wishes to dispose of the laptop. All of this is
188 preceded by a short section on our goals and principles, which serves to
189 provide background to some of the decisions we made, and which might be
190 non-obvious if one thinks of security in the context of normal laptop and
191 desktop machines.
192
</font>
Este documento es completo en cuanto lo que se refiere al modelo de seguridad de la OLPC, pero es generalmente no-técnico. Un documento anexo se encuentra en preparación para complementar este con comentarios y descripciones técnicas completas.
Este documento es completo en cuanto lo que se refiere al modelo de seguridad de la OLPC, pero es generalmente no-técnico. Un documento anexo se encuentra en preparación para complementar este con comentarios y descripciones técnicas completas.
{{ Translated text |
<font size="1">
This document follows security throughout the life-cycle of the laptop itself, starting from the moment a laptop is produced in the factory, to the moment it first reaches a child, throughout the child's use of the laptop, and finally stopping at the moment a child wishes to dispose of the laptop. All of this is preceded by a short section on our goals and principles, which serves to provide background to some of the decisions we made, and which might be non-obvious if one thinks of security in the context of normal laptop and desktop machines.
193 This document is complete with regard to the OLPC security model, but is
194 generally non-technical. A separate document is being prepared that complements
195 this one with fully technical descriptions and commentary.
196
197
198
</font>


This document is complete with regard to the OLPC security model, but is generally non-technical. A separate document is being prepared that complements this one with fully technical descriptions and commentary.
| display = block }}

{{anchor|Chapter 0.4}}{{anchor|Principles and goals}}
== Principios y objetivos ==
== Principios y objetivos ==

199 0.4. Principles and goals
{{anchor|Principles}}
200 -------------------------
201
=== Principios ===
=== Principios ===

202 === Principles ===
; Diseño abierto : La seguridad de la laptop no puede depender de algun diseño secreto implantado en el hardware o software.
203
; Diseño abierto : La seguridad de la laptop no puede depender de algun diseño secreto implantado en el hardware o software
204 * Open design
205 The laptop's security must not depend upon a secret design implemented in
206 hardware or software.
207
; Sin bloqueos : A pesar que varios parametros por defecto, el sistema de seguridad de la laptop puede imponer varias prohibiciones a las acciones del usuario, debe existir la manera por la cual éstos sistemas de seguridad puedan ser deshabilitados. En dicho caso, la máquina le permitirá al usuario un control absoluto.
; Sin bloqueos : A pesar que varios parametros por defecto, el sistema de seguridad de la laptop puede imponer varias prohibiciones a las acciones del usuario, debe existir la manera por la cual éstos sistemas de seguridad puedan ser deshabilitados. En dicho caso, la máquina le permitirá al usuario un control absoluto.
208 * No lockdown
209 Though in their default settings, the laptop's security systems may impose
210 various prohibitions on the user's actions, there must exist a way for these
211 security systems to be disabled. When that is the case, the machine will
212 grant the user complete control.
213
; Sin lecturas requeridas : La seguridad no puede depender de la habilidad del usuario de leer un mensaje de la computadora y actuar de manera informada y razonable. Si bien el deshabilitar un mecanísmo particular ''puede'' requerir una lectura, la máquina debe ser segura desde la fábrica si es entregada a algún usuario que todavía no sabe leer.
; Sin lecturas requeridas : La seguridad no puede depender de la habilidad del usuario de leer un mensaje de la computadora y actuar de manera informada y razonable. Si bien el deshabilitar un mecanísmo particular ''puede'' requerir una lectura, la máquina debe ser segura desde la fábrica si es entregada a algún usuario que todavía no sabe leer.
214 * No reading required
215 Security cannot depend upon the user's ability to read a message from the
216 computer and act in an informed and sensible manner. While disabling a
217 particular security mechanism _may_ require reading, a machine must be secure
218 out of the factory if given to a user who cannot yet read.
219
; Seguridad que no obstruya : Siempre que sea posible, la seguridad en las máquinas debe realizarse tras bambalinas, haciendose notar sólamente por medio de sutiles indicadores visuales o audio, y nunca interponiéndose en el camino del usuario. De existir un conflicto leve frente a la comodidad del usuario, la seguridad máxima toma precedencia, aunque cuidados extremos deben llevarse a cabo con el fin de asegurarse que dichos permisos no reduzcan seriamente o solapadamente la usabilidad de las máquinas.
; Seguridad que no obstruya : Siempre que sea posible, la seguridad en las máquinas debe realizarse tras bambalinas, haciendose notar sólamente por medio de sutiles indicadores visuales o audio, y nunca interponiéndose en el camino del usuario. De existir un conflicto leve frente a la comodidad del usuario, la seguridad máxima toma precedencia, aunque cuidados extremos deben llevarse a cabo con el fin de asegurarse que dichos permisos no reduzcan seriamente o solapadamente la usabilidad de las máquinas.
:Por ejemplo, si un programa es descubierto en el intento de violar una medida de seguridad, no se le preguntará al usuario para permitir dicha acción; que será simplemente negada. Si el usuario desea otorgar dicho permiso, ello puede ser hecho en la interfaz gráfica del centro de seguridad.
:Por ejemplo, si un programa es descubierto en el intento de violar una medida de seguridad, no se le preguntará al usuario para permitir dicha acción; que será simplemente negada. Si el usuario desea otorgar dicho permiso, ello puede ser hecho en la interfaz gráfica del centro de seguridad.
{{ Translated text |
220 * Unobtrusive security
; Open design : The laptop's security must not depend upon a secret design implemented in hardware or software.
221 Whenever possible, the security on the machines must be behind the scenes,
; No lockdown : Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control.
222 making its presence known only through subtle visual or audio cues, and never
; No reading required : Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism _may_ require reading, a machine must be secure out of the factory if given to a user who cannot yet read.
223 getting in the user's way. Whenever in conflict with slight user convenience,
; Unobtrusive security : Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines.
224 strong unobtrusive security is to take precedence, though utmost care must be
: As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.
225 taken to ensure such allowances do not seriously or conspicuously reduce the
| display = block }}
226 usability of the machines.

227
{{anchor|Goals}}
228 As an example, if a program is found attempting to violate a security
229 setting, the user will not be prompted to permit the action; the action will
230 simply be denied. If the user wishes to grant permission for such an action,
231 she can do so through the graphical security center interface.
232
233
=== Objetivos ===
=== Objetivos ===

234 === Goals ===
235
; Sin claves de usuario : Con usuarios jóvenes (a partir de los cinco años), la seguridad de la laptop no puede depender del habilidad del usuario de recordar una clave. No se puede suponer que los usuarios elijan una clave cuando las reciban por primera vez.
; Sin claves de usuario : Con usuarios jóvenes (a partir de los cinco años), la seguridad de la laptop no puede depender del habilidad del usuario de recordar una clave. No se puede suponer que los usuarios elijan una clave cuando las reciban por primera vez.
236 * No user passwords
237 With users as young as 5 years old, the security of the laptop cannot depend
238 on the user's ability to remember a password. Users cannot be expected to
239 choose passwords when they first receive computers.
240
; Sin autentificación no-encriptada : La autentificación de las laptops o sus usuarios no dependerá de identificadores transmitidos sin encriptar en la red. Esto quiere decir que claves ''visibles'' de ningún tipo pueden ser usadas en los protocolos OLPC y que el MAC de Ethernet jamás serán usados como autentificación.
; Sin autentificación no-encriptada : La autentificación de las laptops o sus usuarios no dependerá de identificadores transmitidos sin encriptar en la red. Esto quiere decir que claves ''visibles'' de ningún tipo pueden ser usadas en los protocolos OLPC y que el MAC de Ethernet jamás serán usados como autentificación.
241 * No unencrypted authentication
242 Authentication of laptops or users will not depend upon identifiers that are
243 sent unencrypted over the network. This means no cleartext passwords of any
244 kind will be used in any OLPC protocol and Ethernet MAC addresses will never
245 be used for authentication.
246
; Seguridad desde la caja : La laptop deberá ser usable y segura desde la caja, sin necesidad de realizar o descargar actualizaciones de seguridad en la medidad de lo posible.
; Seguridad desde la caja : La laptop deberá ser usable y segura desde la caja, sin necesidad de realizar o descargar actualizaciones de seguridad en la medidad de lo posible.
247 * Out-of-the-box security
248 The laptop should be both usable and secure out-of-the-box, without the need
249 to download security updates when at all possible.
250
; Uso limitado de [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] institucional : La laptop estará provista con llaves públicas de la OLPC y la autoridad del el país o región (ej: ministerio o departamento de educación), pero estas llaves no serán usadas para validar la identidad de los usuarios. El único propósito de estas llaves es verificar la integridad del software y contenido incluído en la laptop. Los usuarios serán identificados por medio de un sistema orgánico [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] sin una cadena de confianza certificada (''without a certified chain of trust'')&mdash;en otras palabras, nuestro enfoque a [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] es KCM (''Key-Continuity Management'').
; Uso limitado de [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] institucional : La laptop estará provista con llaves públicas de la OLPC y la autoridad del el país o región (ej: ministerio o departamento de educación), pero estas llaves no serán usadas para validar la identidad de los usuarios. El único propósito de estas llaves es verificar la integridad del software y contenido incluído en la laptop. Los usuarios serán identificados por medio de un sistema orgánico [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] sin una cadena de confianza certificada (''without a certified chain of trust'')&mdash;en otras palabras, nuestro enfoque a [http://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica PKI] es KCM (''Key-Continuity Management'').
251 * Limited institutional PKI
252 The laptop will be supplied with public keys from OLPC and the country or
253 regional authority (e.g. the ministry or department of education), but these
254 keys will not be used to validate the identity of laptop users. The sole
255 purpose of these keys will be to verify the integrity of bundled software and
256 content. Users will be identified through an organically-grown PKI without a
257 certified chain of trust -- in other words, our approach to PKI is KCM, or
258 key continuity management.
259
; Sin pérdida permanente de datos : La información en la laptop será replicada sobre algún almacenamiento centralizado de modo tal que el estudiante pueda recuperarla en el caso que la laptop se pierda, sea robada o destruida.
; Sin pérdida permanente de datos : La información en la laptop será replicada sobre algún almacenamiento centralizado de modo tal que el estudiante pueda recuperarla en el caso que la laptop se pierda, sea robada o destruida.
{{ Translated text |
260 * No permanent data loss
; No user passwords : With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers.
261 Information on the laptop will be replicated to some centralized storage
; No unencrypted authentication : Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication.
262 place so that the student can recover it in the even that the laptop is lost,
; Out-of-the-box security : The laptop should be both usable and secure out-of-the-box, without the need to download security updates when at all possible.
263 stolen or destroyed.
; Limited institutional PKI : The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust -- in other words, our approach to PKI is KCM, or key continuity management.
264
; No permanent data loss : Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the even that the laptop is lost, stolen or destroyed.
265
| display = block }}
266

267
{{anchor|Chapter 1}}{{anchor|Factory production}}
= Producción en planta =
= Producción en planta =
<font size="1">
268 1. Factory production
269 =====================
270
</font>


Como parte de su proceso de producción en la planta, ciertos datos relativos a su manufactura son grabados en un chip flash SPI embarcado. El chip es re-escribible, pero obviando la manipulación del hardware, solamente por un proceso de confianza que no dañará o modificará dicha información.
Como parte de su proceso de producción en la planta, ciertos datos relativos a su manufactura son grabados en un chip flash SPI embarcado. El chip es re-escribible, pero obviando la manipulación del hardware, solamente por un proceso de confianza que no dañará o modificará dicha información.
<font size="1">
271 As part of factory production, certain manufacturing data is written to the
272 built-in SPI flash chip. The chip is rewritable, but barring hardware tampering,
273 only by a trusted process that will not damage or modify the manufacturing
274 information.
275
</font>


Los datos de manufactura incluyen dos identificadores únicos: NS, el número de serie (o ''SN - serial number'') y U#, un [http://en.wikipedia.org/wiki/Uuid UUID] (''universally unique identifier'') generado al azar. Los números de serie no son asignados secuencialmente; sino que son elegidos al azar a partir de un conjunto de enteros. El proceso de manufactura mantiene la correspondencia entre numero de serie asignado al azar con el número de serie real secuencial que comenzó en 1 con la primera laptop producida. Esta correspondencia es confidencial pero no secreta, y es mantenida por la OLPC.
Los datos de manufactura incluyen dos identificadores únicos: NS, el número de serie (o ''SN - serial number'') y U#, un [http://en.wikipedia.org/wiki/Uuid UUID] (''universally unique identifier'') generado al azar. Los números de serie no son asignados secuencialmente; sino que son elegidos al azar a partir de un conjunto de enteros. El proceso de manufactura mantiene la correspondencia entre numero de serie asignado al azar con el número de serie real secuencial que comenzó en 1 con la primera laptop producida. Esta correspondencia es confidencial pero no secreta, y es mantenida por la OLPC.
{{ Translated text |
<font size="1">
As part of factory production, certain manufacturing data is written to the built-in SPI flash chip. The chip is rewritable, but barring hardware tampering, only by a trusted process that will not damage or modify the manufacturing information.
276 Manufacturing data includes two unique identifiers: SN, the serial number,

277 and U#, the randomly-generated UUID. Serial numbers are not assigned in
Manufacturing data includes two unique identifiers: SN, the serial number, and U#, the randomly-generated UUID. Serial numbers are not assigned in order; instead, they are chosen randomly from a pool of integers. The manufacturing process maintains a mapping of the random serial number assigned, to the real, incremental serial number which was set to 1 for the first laptop produced. This mapping is confidential but not secret, and is kept by OLPC.
278 order; instead, they are chosen randomly from a pool of integers. The
| display = block }}
279 manufacturing process maintains a mapping of the random serial number assigned,
280 to the real, incremental serial number which was set to 1 for the first laptop
281 produced. This mapping is confidential but not secret, and is kept by OLPC.
282
</font>


El único objetivo de esta correspondencia al azar es para desalentar cualquier intento de usar los números de series de las laptops entregadas en diferentes países para intentar analizar los volúmenes de compra de cada país.
El único objetivo de esta correspondencia al azar es para desalentar cualquier intento de usar los números de series de las laptops entregadas en diferentes países para intentar analizar los volúmenes de compra de cada país.
<font size="1">
283 The random mapping's sole purpose is to discourage attempts at using serial
284 numbers of laptops delivered to different countries for attempting to analyze
285 countries' purchase volumes.
286
</font>


El UUID de cada laptop, U#, es una secuencia al azar de 32 bytes ASCII imprimibles.
El UUID de cada laptop, U#, es una secuencia al azar de 32 bytes ASCII imprimibles.
<font size="1">
287 A laptop's UUID, U#, is a random 32-byte printable ASCII identifier.
288
</font>


En una de las etapas de diagnósticos en la planta tras haber sido producida, la herramienta de diagnóstico enviará toda la información relacionada a su manufactura, incluyendo el U#, NS y la información de la planta a un servidor de la OLPC. Esta información será encolada en la planta ante cualquier problema de conectividad, y por lo tanto no se perderá bajo ninguna situación prevista.
En una de las etapas de diagnósticos en la planta tras haber sido producida, la herramienta de diagnóstico enviará toda la información relacionada a su manufactura, incluyendo el U#, NS y la información de la planta a un servidor de la OLPC. Esta información será encolada en la planta ante cualquier problema de conectividad, y por lo tanto no se perderá bajo ninguna situación prevista.
<font size="1">
289 In one of the factory diagnostics stages after each laptop's production, the
290 diagnostics tool will send the complete manufacturing information, including U#,
291 SN, and factory information, to an OLPC server. This information will be queued
292 at the factory in case of connectivity issues, and so won't be lost under any
293 foreseeable circumstances.
294
</font>


Al salir de la linea de producción, la laptop se encuentra en modo "desactivada". Esto quiere decir que deberá pasar por el proceso de activación criptográfica cuando sea encendida, antes de poder ser usada por el usuario final.
Al salir de la linea de producción, la laptop se encuentra en modo "desactivada". Esto quiere decir que deberá pasar por el proceso de activación criptográfica cuando sea encendida, antes de poder ser usada por el usuario final.
{{ Translated text |
<font size="1">
The random mapping's sole purpose is to discourage attempts at using serial numbers of laptops delivered to different countries for attempting to analyze countries' purchase volumes.
295 At the end of the production line, the laptop is in the 'deactivated' state.

296 This means it must undergo a cryptographic activation process when powered on,
A laptop's UUID, U#, is a random 32-byte printable ASCII identifier.
297 before it can be used by an end user.

298
In one of the factory diagnostics stages after each laptop's production, the diagnostics tool will send the complete manufacturing information, including U#, SN, and factory information, to an OLPC server. This information will be queued at the factory in case of connectivity issues, and so won't be lost under any foreseeable circumstances.
299

300
At the end of the production line, the laptop is in the 'deactivated' state. This means it must undergo a cryptographic activation process when powered on, before it can be used by an end user.
301
| display = block }}
</font>


{{anchor|Chapter 2}}{{anchor|Delivery chain security}}
= Seguridad en la cadena de distribución =
= Seguridad en la cadena de distribución =
<font size="1">
302 2. Delivery chain security
303 ==========================
304
</font>


La OLPC solo se encarga del embarque de las laptops de su planta de origen al país comprador. El despacho y distribución dentro de cada país es totalmente organizado y responsabilidad de cada país.
La OLPC solo se encarga del embarque de las laptops de su planta de origen al país comprador. El despacho y distribución dentro de cada país es totalmente organizado y responsabilidad de cada país.
<font size="1">
305 OLPC arranges only the shipment of laptops from their origin factory to each
306 purchasing country. Shipping and delivery within each country is organized fully
307 by the country.
308
</font>


Dados los volúmenes de producción de la OLPC, la cadena de distribución supone un vector de ataque atractivo para un ladrón emprendedor. El requerimiento para la activación torna el robo en la etapa de entrega inapetecible, requiriendo una intervención a nivel de hardware sobre cada laptop robada antes de su reventa. Damos una revista al proceso de activación más abajo.
Dados los volúmenes de producción de la OLPC, la cadena de distribución supone un vector de ataque atractivo para un ladrón emprendedor. El requerimiento para la activación torna el robo en la etapa de entrega inapetecible, requiriendo una intervención a nivel de hardware sobre cada laptop robada antes de su reventa. Damos una revista al proceso de activación más abajo.
{{ Translated text |
<font size="1">
OLPC arranges only the shipment of laptops from their origin factory to each purchasing country. Shipping and delivery within each country is organized fully by the country.
309 Given OLPC production volumes, the delivery chain poses an attractive attack
310 vector for an enterprising thief. The activation requirement makes delivery
311 theft highly unappealing, requiring hardware intervention to disable on each
312 stolen laptop before resale. We give an overview of the activation process
313 below.
314
315
316
317
</font>


Given OLPC production volumes, the delivery chain poses an attractive attack vector for an enterprising thief. The activation requirement makes delivery theft highly unappealing, requiring hardware intervention to disable on each stolen laptop before resale. We give an overview of the activation process below.
| display = block }}

{{anchor|Chapter 3}}{{anchor|Arrival at school site and activation}}
= Arribo a la escuela y activacion =
= Arribo a la escuela y activacion =
<font size="1">
318 3. Arrival at school site and activation
319 ========================================
320
</font>


Antes que una partida sea despachada a cada escuela, el país utiliza un software provisto por la OLPC para generar una partida de códigos de activación. Esta "lista de activación" posee la tupla (NS, UUID) y su correspondiente código de activación único para cada laptop referenciada. Las listas de activación son generadas por el mismo pais, a medida que las laptops son organizadas en partidas para ser entregadas a escuelas específicas. En otras palabras, no existe una lista maestra de activación.
Antes que una partida sea despachada a cada escuela, el país utiliza un software provisto por la OLPC para generar una partida de códigos de activación. Esta "lista de activación" posee la tupla (NS, UUID) y su correspondiente código de activación único para cada laptop referenciada. Las listas de activación son generadas por el mismo pais, a medida que las laptops son organizadas en partidas para ser entregadas a escuelas específicas. En otras palabras, no existe una lista maestra de activación.
<font size="1">
321 Before a batch of laptops is shipped to each school, the country uses
322 OLPC-provided software to generate a batch of activation codes. This "activation
323 list" maps each (SN, UUID) tuple to a unique activation code for the referenced
324 laptop. Activation lists are generated on-demand by the country for each laptop
325 batch, as the laptops are partitioned into batches destined for specific
326 schools. In other words, there is no master activation list.
327
</font>


La lista de activación para cada partida de laptops es cargada a un disco USB, y entregada al responsable de las entregas del proyecto en la escuela destinataria fuera del circuito de entrega efectivo de las laptops. Este responsable de las entregas será comunmente un maestro u otro funcionario administrativo de la escuela. La lista de activación enviada a una escuela no puede ser usada para activar ninguna otra partida.
La lista de activación para cada partida de laptops es cargada a un disco USB, y entregada al responsable de las entregas del proyecto en la escuela destinataria fuera del circuito de entrega efectivo de las laptops. Este responsable de las entregas será comunmente un maestro u otro funcionario administrativo de la escuela. La lista de activación enviada a una escuela no puede ser usada para activar ninguna otra partida.
{{ Translated text |
<font size="1">
Before a batch of laptops is shipped to each school, the country uses OLPC-provided software to generate a batch of activation codes. This "activation list" maps each (SN, UUID) tuple to a unique activation code for the referenced laptop. Activation lists are generated on-demand by the country for each laptop batch, as the laptops are partitioned into batches destined for specific schools. In other words, there is no master activation list.
328 The activation list for a laptop batch is loaded onto a USB drive, and delivered

329 to a project handler in the target school out of band from the actual laptop
330 shipment. The handler will be commonly a teacher or other school administrator.
The activation list for a laptop batch is loaded onto a USB drive, and delivered to a project handler in the target school out of band from the actual laptop shipment. The handler will be commonly a teacher or other school administrator. The activation list sent to one school cannot be used to activate any other laptop batch.
| display = block }}
331 The activation list sent to one school cannot be used to activate any other
332 laptop batch.
333
</font>


Cuando el la lista de activación en el disco USB es recibida, este será conectado al servidor provisto por la OLPC, u otro servidor que pueda ejecutar el software requerido y que se encuentre conectado a un punto de acceso inalámbrico. Cualquier servidor que tome este rol será referido como el 'servidor de activación'. Una laptop XO activada podría ser usada para este propósito de ser necesario.
Cuando el la lista de activación en el disco USB es recibida, este será conectado al servidor provisto por la OLPC, u otro servidor que pueda ejecutar el software requerido y que se encuentre conectado a un punto de acceso inalámbrico. Cualquier servidor que tome este rol será referido como el 'servidor de activación'. Una laptop XO activada podría ser usada para este propósito de ser necesario.
<font size="1">
334 When the activation list USB drive is received, it is plugged into the
335 OLPC-provided school server, or another server running the requisite software
336 that is connected to a wireless access point. Whichever server takes on this
337 role will be called the 'activation server'. An activated XO laptop can be used
338 for this purpose, if necessary.
339
</font>


Tras la recepción de la partida de laptops correspondiente, el responsable de distribución de la escuela tendrá la tarea de entregar a cada chico su laptop. Cuando un chico reciba una laptop, esta estará aún desactivada. Será el chico quien deberá encender la laptop dentro del alcance del punto de acceso inalámbrico del servidor de activación. Cuando esto ocurra, la laptop comunicará de forma segura su tupla (NS, UUID) al servidor, el cual retornará el código de activación en cuestión, suponiendo que la tupla se encuentra en la lista de activación, o un error de no ser así.
Tras la recepción de la partida de laptops correspondiente, el responsable de distribución de la escuela tendrá la tarea de entregar a cada chico su laptop. Cuando un chico reciba una laptop, esta estará aún desactivada. Será el chico quien deberá encender la laptop dentro del alcance del punto de acceso inalámbrico del servidor de activación. Cuando esto ocurra, la laptop comunicará de forma segura su tupla (NS, UUID) al servidor, el cual retornará el código de activación en cuestión, suponiendo que la tupla se encuentra en la lista de activación, o un error de no ser así.
{{ Translated text |
<font size="1">
When the activation list USB drive is received, it is plugged into the OLPC-provided school server, or another server running the requisite software that is connected to a wireless access point. Whichever server takes on this role will be called the 'activation server'. An activated XO laptop can be used for this purpose, if necessary.
340 After receiving the matching laptop batch, the school's project handler will be

341 tasked with giving a laptop to each child at the school. When a child receives
After receiving the matching laptop batch, the school's project handler will be tasked with giving a laptop to each child at the school. When a child receives a laptop, it is still disabled. The child must power on the laptop within wireless range of the school's activation server. When this happens, the laptop will securely communicate its (SN, UUID) tuple to the server, which will return the activation code for the laptop in question, provided the tuple is found in the activation list, or an error if it isn't.
342 a laptop, it is still disabled. The child must power on the laptop within
| display = block }}
343 wireless range of the school's activation server. When this happens, the laptop
344 will securely communicate its (SN, UUID) tuple to the server, which will return
345 the activation code for the laptop in question, provided the tuple is found in
346 the activation list, or an error if it isn't.
347
</font>


Dado un código de activación inválido o un error, la laptop dormirá durante una hora antes de volver a intentar su activación. Si el código de activación es válido, la laptop esta 'activada', y procede a la primera pantalla de encendido. Un código de activación textual puede ser ingresado manualmente en la máquina, si no se activara automáticamente por alguna razón.
Dado un código de activación inválido o un error, la laptop dormirá durante una hora antes de volver a intentar su activación. Si el código de activación es válido, la laptop esta 'activada', y procede a la primera pantalla de encendido. Un código de activación textual puede ser ingresado manualmente en la máquina, si no se activara automáticamente por alguna razón.
{{ Translated text |
<font size="1">
348 Given an invalid activation code or an error, the laptop will sleep for one
Given an invalid activation code or an error, the laptop will sleep for one hour before retrying activation. If the activation code is valid, the laptop becomes 'activated', and proceeds to boot to the first-boot screen. A textual activation code can be entered into the machine manually, if the machine is not activating automatically for any reason.
| display = block }}
349 hour before retrying activation. If the activation code is valid, the laptop
350 becomes 'activated', and proceeds to boot to the first-boot screen. A textual
351 activation code can be entered into the machine manually, if the machine is not
352 activating automatically for any reason.
353
354
355
356
</font>


{{anchor|Chapter 4}}{{anchor|First boot}}
= Primer encendido =
= Primer encendido =
<font size="1">
357 4. First boot
358 =============
359
</font>


La primera vez que se enciende, un programa se ejecuta preguntandole al chico su nombre, toma una foto, y genera el par de claves [http://es.wikipedia.org/wiki/Criptograf%C3%ADa_de_curva_el%C3%ADptica ECC] en el interin. El par de claves no se encuentra inicialmente protegido por una frase de paso (''passphrase'') y es asi usada para firmar tanto el nombre como la foto del chico. Esta informacion y la firma son la 'identidad digital' del chico.
La primera vez que se enciende, un programa se ejecuta preguntandole al chico su nombre, toma una foto, y genera el par de claves [http://es.wikipedia.org/wiki/Criptograf%C3%ADa_de_curva_el%C3%ADptica ECC] en el interin. El par de claves no se encuentra inicialmente protegido por una frase de paso (''passphrase'') y es asi usada para firmar tanto el nombre como la foto del chico. Esta informacion y la firma son la 'identidad digital' del chico.
<font size="1">
360 On first boot, a program is run that asks the child for their name, takes
361 their picture, and in the background generates an ECC key pair. The key pair is
362 initially not protected by a passphrase, and is then used to sign the child's
363 name and picture. This information and the signature are the child's 'digital
364 identity'.
365
</font>


La laptop transmite la tupla (NS, UUID, identidad digital) al servidor de activación. La correspondencia entre la laptop y la identidad del usuario es mantenida por las autoridades regionales o nacionales con fines anti-robo, pero nunca llega a la OLPC.
La laptop transmite la tupla (NS, UUID, identidad digital) al servidor de activación. La correspondencia entre la laptop y la identidad del usuario es mantenida por las autoridades regionales o nacionales con fines anti-robo, pero nunca llega a la OLPC.
<font size="1">
366 The laptop transmits the (SN, UUID, digital identity) tuple to the activation
367 server. The mapping between a laptop and the user's identity is maintained by
368 the country or regional authority for anti-theft purposes, but never reaches
369 OLPC.
370
</font>


Después de esto, la laptop se inicia normalmente, con toda la seguridad activada.
Después de esto, la laptop se inicia normalmente, con toda la seguridad activada.
{{ Translated text |
<font size="1">
On first boot, a program is run that asks the child for their name, takes their picture, and in the background generates an ECC key pair. The key pair is initially not protected by a passphrase, and is then used to sign the child's name and picture. This information and the signature are the child's 'digital identity'.
371 After this, the laptop boots normally, with all security settings enabled.

372
The laptop transmits the (SN, UUID, digital identity) tuple to the activation server. The mapping between a laptop and the user's identity is maintained by the country or regional authority for anti-theft purposes, but never reaches OLPC.
373

374
After this, the laptop boots normally, with all security settings enabled.
375
| display = block }}
</font>


{{anchor|Chapter 5}}{{anchor|Software installation}}
= Instalación de software =
= Instalación de software =
<font size="1">
376 5. Software installation
377 ========================
378
</font>


Hay una distinción importante entre dos amplios tipos de programas que se ejecutan en un sistema, y esta distinción no usualmente es mencionada en la literatura sobre seguridad. Existen programas que son intencionalmente maliciosos, implicando que son escritos con dichos fines desde un principio, como los virus y ''worms'', y otros programas que son circunstancialmente maliciosos pero que de otro modo son benignos, tales como programas legítimos que han sido vulnerados por un atacante mientras se ejecutan, y son utilizados para ejecutar código para el atacante por medio de la inyección de código u otro mecanismo.
Hay una distinción importante entre dos amplios tipos de programas que se ejecutan en un sistema, y esta distinción no usualmente es mencionada en la literatura sobre seguridad. Existen programas que son intencionalmente maliciosos, implicando que son escritos con dichos fines desde un principio, como los virus y ''worms'', y otros programas que son circunstancialmente maliciosos pero que de otro modo son benignos, tales como programas legítimos que han sido vulnerados por un atacante mientras se ejecutan, y son utilizados para ejecutar código para el atacante por medio de la inyección de código u otro mecanismo.
<font size="1">
379 There is a very important distinction between two broad classes of programs
380 that execute on a running system, and this distinction is not often mentioned
381 in security literature. There are programs that are purposely malicious,
382 which is to say that they were written with ill intent from the start, such as
383 with viruses and worms, and there are programs which are circumstantially
384 malicious but otherwise benign, such as legitimate programs that have been
385 exploited by an attacker while they're running, and are now being instrumented
386 to execute code on behalf of the attacker via code injection or some other
387 method.
388
</font>


Esta diferenciación es crucial y no puede ser subestimada, pues es un supuesto razonable que la mayor parte del software ejecutandose en una máquina normal comienza como benigno. De hecho, hemos observado que es por medio de la usurpación del software benigno que la mayor parte del software maligno es _introducido_ por primera vez en muchas máquinas, por lo tanto, el proteger al software benigno se convierte en algo doblemente importante.
Esta diferenciación es crucial y no puede ser subestimada, pues es un supuesto razonable que la mayor parte del software ejecutandose en una máquina normal comienza como benigno. De hecho, hemos observado que es por medio de la usurpación del software benigno que la mayor parte del software maligno es _introducido_ por primera vez en muchas máquinas, por lo tanto, el proteger al software benigno se convierte en algo doblemente importante.
{{ Translated text |
<font size="1">
There is a very important distinction between two broad classes of programs that execute on a running system, and this distinction is not often mentioned in security literature. There are programs that are purposely malicious, which is to say that they were written with ill intent from the start, such as with viruses and worms, and there are programs which are circumstantially malicious but otherwise benign, such as legitimate programs that have been exploited by an attacker while they're running, and are now being instrumented to execute code on behalf of the attacker via code injection or some other method.
389 This difference is crucial and cannot be understated, because it's a

390 reasonable assumption that most software running on a normal machine starts
391 benign. In fact, we observe that it is through exploitation of benign software
This difference is crucial and cannot be understated, because it's a reasonable assumption that most software running on a normal machine starts benign. In fact, we observe that it is through exploitation of benign software that most malicious software is first _introduced_ to many machines, so protecting benign software becomes a doubly worthy goal.
| display = block }}
392 that most malicious software is first _introduced_ to many machines, so
393 protecting benign software becomes a doubly worthy goal.
394
</font>


La protección del software benigno es una piedra fundamental en nuestro modelo de seguridad. Y lo utilizamos con la siguiente idea en mente: el software benigno no mentirá sobre sus propósitos durante su instalación.
La protección del software benigno es una piedra fundamental en nuestro modelo de seguridad. Y lo utilizamos con la siguiente idea en mente: el software benigno no mentirá sobre sus propósitos durante su instalación.
<font size="1">
395 The protection of benign software is a keystone of our security model. We
396 approach it with the following idea in mind: benign software will not lie about
397 its purpose during installation.
398
</font>


Como ejemplo, tomemos el juego de Solitario distribuído con muchas versiones de Microsoft Windows. Dicho programa no necesita:
Como ejemplo, tomemos el juego de Solitario distribuído con muchas versiones de Microsoft Windows. Dicho programa no necesita:
Line 552: Line 249:
* ninguna capacidad para utilizar la cámara o micrófono embarcados
* ninguna capacidad para utilizar la cámara o micrófono embarcados
* ninguna capacidad para mirar, o modificar, otros programas
* ninguna capacidad para mirar, o modificar, otros programas
{{ Translated text |
<font size="1">
The protection of benign software is a keystone of our security model. We approach it with the following idea in mind: benign software will not lie about its purpose during installation.
399 To provide an example, consider the Solitaire game shipped with most versions

400 of Microsoft Windows. This program needs:
To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:
401
402 * no network access whatsoever
* no network access whatsoever
403 * no ability to read the user's documents
* no ability to read the user's documents
404 * no ability to utilize the built-in camera or microphone
* no ability to utilize the built-in camera or microphone
405 * no ability to look at, or modify, other programs
* no ability to look at, or modify, other programs
| display = block }}
406
</font>


Y si de algún modo es vulnerado por un atacante, el Solitario es libre de hacer cualquier cosa que desee el atacante, incluyendo:
Y si de algún modo es vulnerado por un atacante, el Solitario es libre de hacer cualquier cosa que desee el atacante, incluyendo:
Line 572: Line 268:
* recibir o enviar correo electrónico a nombre del usuario
* recibir o enviar correo electrónico a nombre del usuario
* hacer ruidos fuertes o embarazosos con los parlantes
* hacer ruidos fuertes o embarazosos con los parlantes
<font size="1">
407 Yet if somehow compromised by an attacker, Solitaire is free to do whatever the
408 attacker wishes, including:
409
410 * read, corrupt or delete the user's documents, spreadsheets, music,
411 photos and any other files
412 * eavesdrop on the user via the camera or microphone
413 * replace the user's wallpaper
414 * access the user's website passwords
415 * infect other programs on the hard drive with a virus
416 * download files to the user's machine
417 * receive or send e-mail on behalf of the user
418 * play loud or embarassing sounds on the speakers
419
</font>


El punto crítico aca no es que el Solitario jamás debería ser permitido el realizar cualquiera de las acciones mencionadas (que claramente no debería), sino que sus creadores _saben_ que jamás debería hacerlas. De esto se deduce que si el sistema tuviera la capacidad por la cual el Solitario indicara esto al momento de su instalación, el Solitario podría renunciar irreversiblemente a ciertos privilegios cuando sea instalado, lo cual limita severamente o destruye totalmente su utilidad para cualquier atacante.
El punto crítico aca no es que el Solitario jamás debería ser permitido el realizar cualquiera de las acciones mencionadas (que claramente no debería), sino que sus creadores _saben_ que jamás debería hacerlas. De esto se deduce que si el sistema tuviera la capacidad por la cual el Solitario indicara esto al momento de su instalación, el Solitario podría renunciar irreversiblemente a ciertos privilegios cuando sea instalado, lo cual limita severamente o destruye totalmente su utilidad para cualquier atacante.
{{ Translated text |
<font size="1">
Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:
420 The critical observation here is not that Solitaire should never have the
* read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files
421 ability to do any of the above (which it clearly shouldn't), but that its
* eavesdrop on the user via the camera or microphone
422 creators _know_ it should never do any of the above. It follows that if the
* replace the user's wallpaper
423 system implemented a facility for Solitaire to indicate this at installation
* access the user's website passwords
424 time, Solitaire could irreversibly shed various privileges the moment it's
* infect other programs on the hard drive with a virus
425 installed, which severely limits or simply destroys its usefulness to an
* download files to the user's machine
426 attacker were it taken over.
* receive or send e-mail on behalf of the user
427
* play loud or embarassing sounds on the speakers
</font>

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators _know_ it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.
| display = block }}


Las laptops XO de la OLPC proveen justamente dicha facilidad. La instalación de programas no pasa simplemente por la ejecución del instalador, que es a su vez otro programa, sino a traves de un servicio de instalación del sistema que sabe cómo instalar paquetes de programas XO. Durante la instalación, el servicio de instalación le preguntará al paquete por los permisos de seguridad deseados, y posteriormente notificará al Servicio de Seguridad apropiadamente. Una vez instalado, la lista de permisos por programa solamente será modificable por el usuario por medio de la interfaz gráfica.
Las laptops XO de la OLPC proveen justamente dicha facilidad. La instalación de programas no pasa simplemente por la ejecución del instalador, que es a su vez otro programa, sino a traves de un servicio de instalación del sistema que sabe cómo instalar paquetes de programas XO. Durante la instalación, el servicio de instalación le preguntará al paquete por los permisos de seguridad deseados, y posteriormente notificará al Servicio de Seguridad apropiadamente. Una vez instalado, la lista de permisos por programa solamente será modificable por el usuario por medio de la interfaz gráfica.
<font size="1">
428 The OLPC XO laptops provide just such a facility. Program installation does
429 not occur through the simple execution of the installer, which is yet another
430 program, but through a system installation service which knows how to install
431 XO program bundles. During installation, the installer service will query
432 the bundle for the program's desired security permissions, and will notify
433 the system Security Service accordingly. After installation, the
434 per-program permission list is only modifiable by the user through a
435 graphical interface.
436
</font>


Un programa benigno como el Solitario simplemente no solicitaría permisos especiales durante su instalación, y llegado su usurpación, sería incapaz de realizar algo particularmente dañino, como alguna de las acciones enumeradas en la lista arriba.
Un programa benigno como el Solitario simplemente no solicitaría permisos especiales durante su instalación, y llegado su usurpación, sería incapaz de realizar algo particularmente dañino, como alguna de las acciones enumeradas en la lista arriba.
{{ Translated text |
<font size="1">
The OLPC XO laptops provide just such a facility. Program installation does not occur through the simple execution of the installer, which is yet another program, but through a system installation service which knows how to install XO program bundles. During installation, the installer service will query the bundle for the program's desired security permissions, and will notify the system Security Service accordingly. After installation, the per-program permission list is only modifiable by the user through a graphical interface.
437 A benign program such as Solitaire would simply not request any special

438 permissions during installation, and if taken over, would not be able to
439 perform anything particularly damaging, such as the actions from the above
A benign program such as Solitaire would simply not request any special permissions during installation, and if taken over, would not be able to perform anything particularly damaging, such as the actions from the above list.
| display = block }}
440 list.
441
</font>


Cabe resaltar que dicho sistema _solo_ protege al software benigno. El problema todavía existe con el software intencionalmente malicioso, que bien podría solicitar todos los permisos durante su instalación y abusarlos arbitrariamente cuando sea ejecutado. Para evitar eso es que hacemos ciertos permisos durante la instalación mutuamente excluyentes, lo cual de hecho torna difícil que un programa malicioso solicite un conjunto de permisos que le permitan facilmente realizar acciones maliciosas. Los detalles de dichos mecanismos se encuentra más adelante en este documento.
Cabe resaltar que dicho sistema _solo_ protege al software benigno. El problema todavía existe con el software intencionalmente malicioso, que bien podría solicitar todos los permisos durante su instalación y abusarlos arbitrariamente cuando sea ejecutado. Para evitar eso es que hacemos ciertos permisos durante la instalación mutuamente excluyentes, lo cual de hecho torna difícil que un programa malicioso solicite un conjunto de permisos que le permitan facilmente realizar acciones maliciosas. Los detalles de dichos mecanismos se encuentra más adelante en este documento.
<font size="1">
442 It must be noted here that this system _only_ protects benign software. The
443 problem still remains of intentionally malicious software, which might request
444 all available permissions during installation in order to abuse them
445 arbitrarily when run. We address this by making certain initially-requestable
446 permissions mutually exclusive, in effect making it difficult for malicious
447 software to request a set of permissions that easily allow malicious action.
448 Details on this mechanism are provided later in this document.
449
</font>


Como nota final, los programas con firmas criptográficas de la OLPC o de los países individuales pueden evitar los límites a la solicitud de permisos, y de hecho solicitar cualquier conjunto de permisos deseado al momento de su instalación.
Como nota final, los programas con firmas criptográficas de la OLPC o de los países individuales pueden evitar los límites a la solicitud de permisos, y de hecho solicitar cualquier conjunto de permisos deseado al momento de su instalación.
{{ Translated text |
<font size="1">
It must be noted here that this system _only_ protects benign software. The problem still remains of intentionally malicious software, which might request all available permissions during installation in order to abuse them arbitrarily when run. We address this by making certain initially-requestable permissions mutually exclusive, in effect making it difficult for malicious software to request a set of permissions that easily allow malicious action. Details on this mechanism are provided later in this document.
450 As a final note, programs cryptographically signed by OLPC or the
451 individual countries may bypass the permission request limits, and request
452 any permissions they wish at installation time.
453
454
455
456
</font>


As a final note, programs cryptographically signed by OLPC or the individual countries may bypass the permission request limits, and request any permissions they wish at installation time.
| display = block }}

{{anchor|Chapter 6}}{{anchor|Software execution: problem statement}}
= Ejecución de software: el problema =
= Ejecución de software: el problema =
<font size="1">
457 6. Software execution: problem statement
458 ========================================
459
</font>


El modelo de riesgo que intentamos lograr mientras la máquina está corriendo es uno difícil: deseamos tener la capacidad de ejecutar código usualmente sin confianza, al mismo tiempo que limitamos severamente su capacidad de producir daño al sistema.
El modelo de riesgo que intentamos lograr mientras la máquina está corriendo es uno difícil: deseamos tener la capacidad de ejecutar código usualmente sin confianza, al mismo tiempo que limitamos severamente su capacidad de producir daño al sistema.
<font size="1">
460 The threat model that we are trying to address while the machine is running
461 normally is a difficult one: we wish to have the ability to execute generally
462 untrusted code, while severely limiting its ability to inflict harm to the
463 system.
464
</font>


Muchos de los dispositivos digitales son más vistos o vendidos como embarcados o computadoras administradas que como laptops o máquinas de escritorio personales (un ejemplo es el [http://www.amdboard.com/pic.html comunicador PIC] de AMD que esquiva el problema del código no confiable completamente, logrando una inmunidad a los virus, ''malware'' y ''spyware'' permitiendo solamente la ejecución exclusiva de código firmado criptográficamente por el vendedor. En la práctica, esto quiere decir que el usuario esta limitado a la utilización de un conjunto muy limitado de programas provistos por el vendedor, y que no puede desarrollar su propio software o utilizar el de terceros. Si bien esta aproximación a la seguridad limita definitivamente ciertos vectores de ataques, debe ser recalcado que no es una solución definitiva (o ''silver bullet''). Una computadora que no puede ser libremente programada representa una disminución enorme en la utilidad a la cual la mayoría de los usuarios se han acostumbrado y esperan&mdash;pero aún si ignoramos esto y nos enfocamos solamente en las calificaciones técnicas de un tal sistema de seguridad, debemos resaltar que casi siempre, las firmas criptográficas de los binarios son revisadas al momento de carga, no continuamente durante su ejecución. Con lo cual, las vulnerabilidades existentes en los binarios provistos por el vendedor aún permiten dañar al sistema. De igual modo, el sistema falla al no proveer ninguna protección contra ataques macro.
Muchos de los dispositivos digitales son más vistos o vendidos como embarcados o computadoras administradas que como laptops o máquinas de escritorio personales (un ejemplo es el [http://www.amdboard.com/pic.html comunicador PIC] de AMD que esquiva el problema del código no confiable completamente, logrando una inmunidad a los virus, ''malware'' y ''spyware'' permitiendo solamente la ejecución exclusiva de código firmado criptográficamente por el vendedor. En la práctica, esto quiere decir que el usuario esta limitado a la utilización de un conjunto muy limitado de programas provistos por el vendedor, y que no puede desarrollar su propio software o utilizar el de terceros. Si bien esta aproximación a la seguridad limita definitivamente ciertos vectores de ataques, debe ser recalcado que no es una solución definitiva (o ''silver bullet''). Una computadora que no puede ser libremente programada representa una disminución enorme en la utilidad a la cual la mayoría de los usuarios se han acostumbrado y esperan&mdash;pero aún si ignoramos esto y nos enfocamos solamente en las calificaciones técnicas de un tal sistema de seguridad, debemos resaltar que casi siempre, las firmas criptográficas de los binarios son revisadas al momento de carga, no continuamente durante su ejecución. Con lo cual, las vulnerabilidades existentes en los binarios provistos por el vendedor aún permiten dañar al sistema. De igual modo, el sistema falla al no proveer ninguna protección contra ataques macro.
{{ Translated text |
<font size="1">
The threat model that we are trying to address while the machine is running normally is a difficult one: we wish to have the ability to execute generally untrusted code, while severely limiting its ability to inflict harm to the system.
465 Many computer devices that are seen or marketed more as embedded or managed

466 computers than personal laptops or desktops (one example is AMD's [[PIC
Many computer devices that are seen or marketed more as embedded or managed computers than personal laptops or desktops (one example is AMD's [[PIC communicator -> http://www.amdboard.com/pic.html]]) purport to dodge the issue of untrusted code entirely, while staving off viruses, malware and spyware by only permitting execution of code cryptographically signed by the vendor. In practice, this means the user is limited to executing a very restricted set of vendor-provided programs, and cannot develop her own software or use software from third party developers. While this approach to security certainly limits available attack vectors, it should be noted it is pointedly not a silver bullet. A computer that is not freely programmable represents a tremendous decrease in utility from what most consumers have come to expect from their computers -- but even if we ignore this and focus merely on the technical qualifications of such a security system, we must stress that almost always, cryptographic signatures for binaries are checked at load time, not continually during execution. Thus exploits for vendor-provided binaries are still able to execute and harm the system. Similarly, this system fails to provide any protection against macro attacks.
467 communicator -> http://www.amdboard.com/pic.html]]) purport to dodge the
| display = block }}
468 issue of untrusted code entirely, while staving off viruses, malware and
469 spyware by only permitting execution of code cryptographically signed by the
470 vendor. In practice, this means the user is limited to executing a very
471 restricted set of vendor-provided programs, and cannot develop her own software
472 or use software from third party developers. While this approach to security
473 certainly limits available attack vectors, it should be noted it is pointedly
474 not a silver bullet. A computer that is not freely programmable represents a
475 tremendous decrease in utility from what most consumers have come to expect
476 from their computers -- but even if we ignore this and focus merely on the
477 technical qualifications of such a security system, we must stress that almost
478 always, cryptographic signatures for binaries are checked at load time, not
479 continually during execution. Thus exploits for vendor-provided binaries are
480 still able to execute and harm the system. Similarly, this system fails to
481 provide any protection against macro attacks.
482
</font>


Como fue mencionado en la introducción, este modelo de ejecución restringido definitivamente no es una opción para las laptops XO. Aún más, queremos explícitamente incentivar y motivar a nuestros usuarios, los chicos, a participar en una situacion que sería una pesadilla para cualquier experto en seguridad: el compartir fácilmente código entre computadoras.
Como fue mencionado en la introducción, este modelo de ejecución restringido definitivamente no es una opción para las laptops XO. Aún más, queremos explícitamente incentivar y motivar a nuestros usuarios, los chicos, a participar en una situacion que sería una pesadilla para cualquier experto en seguridad: el compartir fácilmente código entre computadoras.
<font size="1">
483 As we mention in the introduction, this severely restricted execution model is
484 absolutely not an option for the XO laptops. What's more, we want to explicitly
485 encourage our users, the children, to engage in a scenario certain to give
486 nightmares to any security expert: easy code sharing between computers.
487
</font>


Como parte de nuestra misión educativa, estamos facilitando a los chicos la capacidad de ver el código del programa que esten corriendo&mdash;tanto es así que proveemos la tecla de Ver Código Fuente en el teclado con ese fin&mdash;y también estamos haciendoles igualmente fácil el escribir su propio código en [[Python]], nuestro lenguaje de programación por elección. Dado nuestro continuo enfasis en la colaboración como una característica directamente integrada al sistema operativo, el escenario donde un chico desarrolla algún software y desea compartirlo con sus amigos se convierte en algo natural, y que debe ser bien soportado.
Como parte de nuestra misión educativa, estamos facilitando a los chicos la capacidad de ver el código del programa que esten corriendo&mdash;tanto es así que proveemos la tecla de Ver Código Fuente en el teclado con ese fin&mdash;y también estamos haciendoles igualmente fácil el escribir su propio código en [[Python]], nuestro lenguaje de programación por elección. Dado nuestro continuo enfasis en la colaboración como una característica directamente integrada al sistema operativo, el escenario donde un chico desarrolla algún software y desea compartirlo con sus amigos se convierte en algo natural, y que debe ser bien soportado.
{{ Translated text |
<font size="1">
As we mention in the introduction, this severely restricted execution model is absolutely not an option for the XO laptops. What's more, we want to explicitly encourage our users, the children, to engage in a scenario certain to give nightmares to any security expert: easy code sharing between computers.
488 As part of our educational mission, we're making it very easy for children to

489 see the code of the programs they're running -- we even provide a View
As part of our educational mission, we're making it very easy for children to see the code of the programs they're running -- we even provide a View Source key on the keyboard for this purpose -- and are making it similarly easy for children to write their own code in Python, our programming language of choice. Given our further emphasis on collaboration as a feature integrated directly into the operating system, the scenario where a child develops some software and wishes to share it with her friends becomes a natural one, and one that needs to be well-supported.
490 Source key on the keyboard for this purpose -- and are making it similarly easy
| display = block }}
491 for children to write their own code in Python, our programming language of
492 choice. Given our further emphasis on collaboration as a feature integrated
493 directly into the operating system, the scenario where a child develops some
494 software and wishes to share it with her friends becomes a natural one, and one
495 that needs to be well-supported.
496
</font>


Desafortunadamente, el software recibido por medio de un amigo o conocido carece de toda confianza, dado que no existe una correspondencia de la confianza entre personas y software: confiar en un amigo no es, y no puede ser, lo mismo que confiar el código proveniente de dicho amigo. La máquina del amigo puede estar bajo el control de otro, y puede estar intentando enviar código malicioso a todos sus amigos, o el amigo puede querer estar tratando de hacer una jugarreta, o puede haber escrito&mdash;ya sea por ignorancia o malicia&mdash;software que a veces es malicioso.
Desafortunadamente, el software recibido por medio de un amigo o conocido carece de toda confianza, dado que no existe una correspondencia de la confianza entre personas y software: confiar en un amigo no es, y no puede ser, lo mismo que confiar el código proveniente de dicho amigo. La máquina del amigo puede estar bajo el control de otro, y puede estar intentando enviar código malicioso a todos sus amigos, o el amigo puede querer estar tratando de hacer una jugarreta, o puede haber escrito&mdash;ya sea por ignorancia o malicia&mdash;software que a veces es malicioso.
<font size="1">
497 Unfortunately, software received through a friend or acquaintance is completely
498 untrusted code, because there's no trust mapping between people and software:
499 trusting a friend isn't, and cannot be, the same as trusting code coming from
500 that friend. The friend's machine might be taken over, and may be attempting to
501 send malicious code to all her friends, or the friend might be trying to execute
502 a prank, or he might have written -- either out of ignorance or malice --
503 software that is sometimes malicious.
504
</font>


Es con éste trasfondo que hemos construído las protecciones de seguridad en la laptop. Una oración capaz de resumir las intenciones de nuestro modelo de seguridad completamente es que "intenta prevenir que el software haga cosas malas". El siguiente capítulo explica las cinco categorías de 'cosas malas' que un software malicioso puede hacer, y el capítulo posterior las protecciones mismas. El capítulo 9 explica el rol de cada protección participa dentro del modelo de riesgos.
Es con éste trasfondo que hemos construído las protecciones de seguridad en la laptop. Una oración capaz de resumir las intenciones de nuestro modelo de seguridad completamente es que "intenta prevenir que el software haga cosas malas". El [[#Chapter 7|siguiente capítulo]] explica las cinco categorías de 'cosas malas' que un software malicioso puede hacer, y el [[#Chapter 8|capítulo posterior]] las protecciones mismas. El [[#Chapter 9|capítulo 9]] explica el rol de cada protección participa dentro del modelo de riesgos.
{{ Translated text |
<!-- áéíóú ü ñÑ¡¿©® -->
Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, or he might have written -- either out of ignorance or malice -- software that is sometimes malicious.
<font size="1">

505 It is against this background that we've constructed security protections for
It is against this background that we've constructed security protections for software on the laptop. A one-sentence summary of the intent of our complete software security model is that it "tries to prevent software from doing bad things". The next chapter explains the five categories of 'bad things' that malicious software might do, and the chapter after that our protections themselves. Chapter 9 explains how each protection addresses the threat model.
506 software on the laptop. A one-sentence summary of the intent of our complete
| display = block }}
507 software security model is that it "tries to prevent software from doing bad
508 things". The next chapter explains the five categories of 'bad things' that
509 malicious software might do, and the chapter after that our protections
510 themselves. Chapter 9 explains how each protection addresses the threat model.
511
512
513
514
</font>


{{anchor|Chapter 7}}{{anchor|Threat model: bad things that software can do}}
= Modelo de riesgo: las cosas malas que el software puede hacer =
= Modelo de riesgo: las cosas malas que el software puede hacer =
<font size="1">
515 7. Threat model: bad things that software can do
516 ==================================================
517
</font>


En el contexto y propósito de la discusión, existen cinco grandes categorías de "cosas malas" que la ejecución del software puede realizar. Sin un orden particular, el software puede intentar dañar la máquina, vulnerar la privacidad del usuario, dañar la información del usuario, hacer "cosas malas" a otras personas aparte del usuario de la máquina, y por último, suplantar al usuario.
En el contexto y propósito de la discusión, existen cinco grandes categorías de "cosas malas" que la ejecución del software puede realizar. Sin un orden particular, el software puede intentar dañar la máquina, vulnerar la privacidad del usuario, dañar la información del usuario, hacer "cosas malas" a otras personas aparte del usuario de la máquina, y por último, suplantar al usuario.
{{ Translated text |
<!-- áéíóú ü ñÑ¡¿©® -->
There are five broad categories of "bad things" that running software could do, for the purposes of our discussion. In no particular order, software can attempt to damage the machine, compromise the user's privacy, damage the user's information, do "bad things" to people other than the machine's user, and lastly, impersonate the user.
<font size="1">
| display = block }}
518 There are five broad categories of "bad things" that running software could do,
519 for the purposes of our discussion. In no particular order, software can attempt
520 to damage the machine, compromise the user's privacy, damage the user's
521 information, do "bad things" to people other than the machine's user, and
522 lastly, impersonate the user.
523
524
525
</font>


{{anchor|Chapter 7.1}}{{anchor|Damaging the machine}}
== Dañar la máquina ==
== Dañar la máquina ==
<font size="1">
526 7.1. Damaging the machine
527 -------------------------
528
</font>


El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que&mdash;siendo un chip flash&mdash;tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (''re-imaged'') y activada para su recuperación.
El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que&mdash;siendo un chip flash&mdash;tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (''re-imaged'') y activada para su recuperación.
<font size="1">
529 Software wishing to render a laptop inoperable has at least five attack
530 vectors. It may try to ruin the machine's BIOS, preventing it from booting. It
531 may attempt to run down the NAND chip used for primary storage, which -- being
532 a flash chip -- has a limited number of write/erase cycles before ceasing to
533 function properly and requiring replacement. Successful attacks on the BIOS or
534 NAND cause hard damage to the machine, meaning such laptops require trained
535 hardware intervention, including part replacement, to restore to operation. The
536 third vector, deleting or damaging the operating system, is an annoyance that
537 would require the machine to be re-imaged and reactivated to run.
538
</font>


Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de ''performance'' y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo).
Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de ''performance'' y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo).
{{ Translated text |
<font size="1">
Software wishing to render a laptop inoperable has at least five attack vectors. It may try to ruin the machine's BIOS, preventing it from booting. It may attempt to run down the NAND chip used for primary storage, which -- being a flash chip -- has a limited number of write/erase cycles before ceasing to function properly and requiring replacement. Successful attacks on the BIOS or NAND cause hard damage to the machine, meaning such laptops require trained hardware intervention, including part replacement, to restore to operation. The third vector, deleting or damaging the operating system, is an annoyance that would require the machine to be re-imaged and reactivated to run.
539 Two other means of damaging the machine cause soft damage: they significantly

540 reduce its utility. These attacks are performance degradation and battery
541 drainage (with the side note that variants of the former can certainly cause the
Two other means of damaging the machine cause soft damage: they significantly reduce its utility. These attacks are performance degradation and battery drainage (with the side note that variants of the former can certainly cause the latter.)
| display = block }}
542 latter.)
543
</font>


Cuando nos referimos a la degradación de ''performance'', nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la ''performance'' (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la ''performance'' general; esta sección será actualizada reflejando dicha información.
Cuando nos referimos a la degradación de ''performance'', nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la ''performance'' (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la ''performance'' general; esta sección será actualizada reflejando dicha información.
{{ Translated text |
<!-- áéíóú ü ñÑ¡¿©® -->
When we say performance degradation, we are referring to the over-utilization of any system resource such as RAM, the CPU or the networking chip, in a way that makes the system too slow or unresponsive to use for other purposes. Battery drainage might be a side-effect of such a malicious performance degradation (e.g. because of bypassing normal power saving measures and over-utilization of power-hungry hardware components), or it might be accomplished through some other means. Once we can obtain complete power measurements for our hardware system, we will be aware of whether side channels exist for consuming large amounts of battery power without general performance degradation; this section will be updated to reflect that information.
<font size="1">
| display = block }}
544 When we say performance degradation, we are referring to the over-utilization of
545 any system resource such as RAM, the CPU or the networking chip, in a way that
546 makes the system too slow or unresponsive to use for other purposes. Battery
547 drainage might be a side-effect of such a malicious performance degradation
548 (e.g. because of bypassing normal power saving measures and over-utilization of
549 power-hungry hardware components), or it might be accomplished through some
550 other means. Once we can obtain complete power measurements for our hardware
551 system, we will be aware of whether side channels exist for consuming large
552 amounts of battery power without general performance degradation; this section
553 will be updated to reflect that information.
554
555
556
</font>


{{anchor|Chapter 7.2}}{{anchor|Compromising privacy}}
== Vulnerar la privacidad ==
== Vulnerar la privacidad ==

557 7.2. Compromising privacy
Prevemos dos modos principales del software vulnerando la privacidad del usuario: el envio no autorizado de información perteneciente al usuario como documentos e imagenes por la red, y el espiar al usuario por medio de la cámara y el micrófono incorporado.
558 -------------------------
{{ Translated text |
559
560 We see two primary means of software compromising user privacy: the
We see two primary means of software compromising user privacy: the unauthorized sending of user-owned information such as documents and images over the network, and eavesdropping on the user via the laptops' built-in camera and microphone.
| display = block }}
561 unauthorized sending of user-owned information such as documents and images

562 over the network, and eavesdropping on the user via the laptops' built-in
{{anchor|Chapter 7.3}}{{anchor|Damaging the user's data}}
563 camera and microphone.
== Dañar los datos del usuario ==
564

565
Un programa malicioso puede intentar borrar o corromper los documentos del usuario, crear una gran cantidad de documentos falsos o llenos de basura que le harían difícil al usuario el encontrar los suyos propios, o atacar a otros servicios del sistema que manipulan datos, como el servicio de búsqueda. De hecho, el atacar al servicio de indexación global puede convertirse en un nuevo canal para el ''spam'', que aparecería constantemente cada vez que el usuario buscase algo en su sistema. Seguramente existen otros vectores de ataque.
566
{{ Translated text |
== Daniar los datos del usuario ==
A malicious program can attempt to delete or corrupt the user's documents, create large numbers of fake or garbage-filled documents to make it difficult for the user to find her legitimate ones, or attack other system services that deal with data, such as the search service. Indeed, attacking the global indexing service might well become a new venue for spam, that would thus show up every time the user searched for anything on her system. Other attack vectors undoubtedly exist.
567 7.3. Damaging the user's data
| display = block }}
568 -----------------------------

569
{{anchor|Chapter 7.4}}{{anchor|Doing bad things to other people}}
570 A malicious program can attempt to delete or corrupt the user's documents,
571 create large numbers of fake or garbage-filled documents to make it difficult
572 for the user to find her legitimate ones, or attack other system services that
573 deal with data, such as the search service. Indeed, attacking the global
574 indexing service might well become a new venue for spam, that would thus show
575 up every time the user searched for anything on her system. Other attack
576 vectors undoubtedly exist.
577
578
579
== Hacer cosas malas a otras personas ==
== Hacer cosas malas a otras personas ==

580 7.4. Doing bad things to other people
El software puede ser malicioso de manera tal que no afecta de un modo directo o importante al usuario u operador de la máquina. Algunos ejemplos incluyen el realizar [http://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio ataques de denegación de servicio] (''Denial of Service attack'') contra la red inalámbrica o cableada actual (un logro particularmente fácil sobre redes [http://es.wikipedia.org/wiki/IPv6 IPv6], sobre las cuales nuestras laptops operarán por defecto), convirtiendose en un relay de spam, uniéndose a un ''[http://en.wikipedia.org/wiki/FloodNet floodnet]'' o algún otro ''[http://es.wikipedia.org/wiki/Botnet botnet]''.
581 -------------------------------------
{{ Translated text |
582
583 Software might be malicious in ways that do not directly or strongly affect the
Software might be malicious in ways that do not directly or strongly affect the machine's owner or operator. Examples include performing Denial of Service attacks against the current wireless or wired network (a feat particularly easy on IPv6 networks, which our laptops will operate on by default), becoming a spam relay, or joining a floodnet or other botnet.
| display = block }}
584 machine's owner or operator. Examples include performing Denial of Service

585 attacks against the current wireless or wired network (a feat particularly easy
{{anchor|Chapter 7.5}}{{anchor|Impersonating the user}}
586 on IPv6 networks, which our laptops will operate on by default), becoming a
587 spam relay, or joining a floodnet or other botnet.
588
589
590
== Suplantar al usuario ==
== Suplantar al usuario ==
591 7.5. Impersonating the user
592 ---------------------------
593
594 Malicious software might attempt to abuse the digital identity primitives on
595 the system, such as digital signing, to send messages appearing to come from
596 the user, or to abuse previously authenticated sessions that the user might
597 have created to privileged resources, such as the school server.
598
599
600
601


Un software malicioso puede intentar abusar de las primitivas de identidad digital del sistema, tales como la firma digital, para enviar mensajes que parecerían provenir del usuario, o abusar de sesiones previamente autenticadas que el usuario puede haber creado hacia recursos privilegiados, tales como el servidor escolar.
{{ Translated text |
Malicious software might attempt to abuse the digital identity primitives on the system, such as digital signing, to send messages appearing to come from the user, or to abuse previously authenticated sessions that the user might have created to privileged resources, such as the school server.
| display = block }}

{{anchor|Chapter 8}}{{anchor|Protections}}
= Protecciones =
= Protecciones =

602 8. Protections
Aquí explicamos el conjunto de protecciones que forman el grueso de la plataforma de seguridad Bitfrost, nuestro nombre para la suma total de los sistemas de seguridad de la laptop. Cada protección enumerada a continuación tiene una etiqueta textual concisa que comienza con la letra P. Dicha etiqueta es puramente una conveniencia para su fácil referencia, y significa tanto la política como el mecanismo de un dado sistema de protección.
603 ==============

604
Casi todas las protecciones mencionadas pueden ser deshabilitadas por el usuario por medio de una interfaz gráfica. Mientras las protecciones de la laptop se encuentren activas, dicha interfaz no puede ser manipulada por los programas del sistema de ningún modo, ya sea por medio de eventos sintéticos del teclado o el ratón, o la modificación directa del archivo de configuración.
605 Here, we explain the set of protections that make up the bulk of the Bitfrost
{{ Translated text |
606 security platform, our name for the sum total of the laptop's security systems.
Here, we explain the set of protections that make up the bulk of the Bitfrost security platform, our name for the sum total of the laptop's security systems. Each protection listed below is given a concise uppercase textual label beginning with the letter P. This label is simply a convenience for easy reference, and stands for both the policy and mechanism of a given protection system.
607 Each protection listed below is given a concise uppercase textual label

608 beginning with the letter P. This label is simply a convenience for easy
Almost all of the protections we discuss can be disabled by the user through a graphical interface. While the laptop's protections are active, this interface cannot be manipulated by the programs on the system through any means, be it synthetic keyboard and mouse events or direct configuration file modification.
609 reference, and stands for both the policy and mechanism of a given protection
| display = block }}
610 system.

611
{{anchor|Chapter 8.1}}{{anchor|P_BIOS_CORE}}{{anchor|P_BIOS_CORE: core BIOS protection}}
612 Almost all of the protections we discuss can be disabled by the user through a
613 graphical interface. While the laptop's protections are active, this interface
614 cannot be manipulated by the programs on the system through any means, be
615 it synthetic keyboard and mouse events or direct configuration file
616 modification.
617
618
619
== P_BIOS_CORE: proteccion del nucleo de la BIOS ==
== P_BIOS_CORE: proteccion del nucleo de la BIOS ==

620 8.1. P_BIOS_CORE: core BIOS protection
La [http://es.wikipedia.org/wiki/BIOS BIOS] de una laptop XO reside en un chip flash SPI de 1MiB, mencionado en la seccion 1.1. Su propósito es el de guardar la información de manufactura acerca de la máquina incluyendo su tupla (NS, UUID), la BIOS propia y su firmware. El ''reflasheo'' (''reflashing'') de la BIOS almacenada esta estrictamente controlado, de modo tal que solamente una imagen BIOS firmada criptográficamente por la OLPC pueda ''flasheada' al chip. El firmware no realizará el ''reflasheo'' si el nivel de la batería es bajo, evitando así que la máquina se apague mientras la operación es llevada a cabo.
621 --------------------------------------

622
Un chico puede solicitar una llave o clave conocida como ''clave de desarrollador'' a la OLPC. Esta llave, ligada a la tupla (NS, UUID) de la laptop del chico, le permite al chico ''flashear'' cualquier BIOS que desee, de modo tal de permitir a aquellos chicos que se conviertan en desarrolladores avanzados modificar su propio firmware.
623 The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in Section
{{ Translated text |
624 1.1. This chip's purpose is to hold manufacturing information about the machine
The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in Section 1.1. This chip's purpose is to hold manufacturing information about the machine including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the stored BIOS is strictly controlled, in such a way that only a BIOS image cryptographically signed by OLPC can be flashed to the chip. The firmware will not perform a BIOS reflashing if the battery level is detected as low, to avoid the machine powering off while the operation is in progress.
625 including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the

626 stored BIOS is strictly controlled, in such a way that only a BIOS image
A child may request a so-called developer key from OLPC. This key, bound to the child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she wishes, to accommodate the use case of those children who progress to be very advanced developers and wish to modify their own firmware.
627 cryptographically signed by OLPC can be flashed to the chip. The firmware will
| display = block }}
628 not perform a BIOS reflashing if the battery level is detected as low, to avoid

629 the machine powering off while the operation is in progress.
{{anchor|Chapter 8.2}}{{anchor|P_BIOS_COPY}}{{anchor|P_BIOS_COPY: secondary BIOS protection}}
630
== P_BIOS_COPY: Protección de BIOS secundaria ==
631 A child may request a so-called developer key from OLPC. This key, bound to the

632 child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she
La inclusión de esta protección aún es incierta, y dependerá del tamaño final de la BIOS y el firmware una vez que toda la funcionalidad deseada este incluída. El chip flash SPI provee 1MiB de capacidad; si la BIOS y el firmware pueden ser acomodados en menos de 512KiB, una segunda copia puede ser almacenada en el SPI. Esta copia secundaria sería inmutable (imposible de ''reflashear'') y sería usada para arrancar al sistema en el caso que la BIOS primaria sea inutilizable. Varios factores pueden resultar en dicho estado, principalmente la perdida de energía violenta durante el proceso de ''flasheo'', como ocurriría en el caso de retirar la batería de la máquina, o simplemente un chip SPI defectuoso que no ''reflashea'' correctamente. Esta sección será actualizada una vez que se determine la inclusión o no de dicha protección.
633 wishes, to accommodate the use case of those children who progress to be very
{{ Translated text |
634 advanced developers and wish to modify their own firmware.
The inclusion of this protection is uncertain, and depends on the final size of the BIOS and firmware after all the desired functionality is included. The SPI flash offers 1MB of storage space; if the BIOS and firmware can be made to fit in less than 512KB, a second copy of the bundle will be stored in the SPI. This secondary copy would be immutable (cannot be reflashed) and used to boot the machine in case of the primary BIOS being unbootable. Various factors might lead to such a state, primarily hard power loss during flashing, such as through the removal of the battery from the machine, or simply a malfunctioning SPI chip which does not reflash correctly. This section will be updated once it becomes clear whether this protection can be included.
635
| display = block }}
636

637
{{anchor|Chapter 8.3}}{{anchor|P_SF_CORE}}{{anchor|P_SF_CORE: core system file protection}}
== P_BIOS_COPY: Proteccion de la BIOS secundaria ==
== P_SF_CORE: Protección de archivos del núcleo del sistema ==
638 8.2. P_BIOS_COPY: secondary BIOS protection

639 -----------------------------------------------
La protección de los archivos del núcleo del sistema impide las modificaciones del sistema almacenado en la memoria flash NAND de la laptop, que es usado como su almacenamiento primario. Cuando se encuentra activa, esta protección controla que ningún proceso altere de cualquier modo los archivos del sistema distribuídos como parte del SO OLPC.
640

641 The inclusion of this protection is uncertain, and depends on the final size of
Esta protección no puede ser deshabilitada sin una ''llave de desarrollador'' (''developer key''), mencionada en la Sección 8.1.
642 the BIOS and firmware after all the desired functionality is included. The SPI
{{ Translated text |
643 flash offers 1MB of storage space; if the BIOS and firmware can be made to fit
The core system file protection disallows modification of the stored system image on a laptop's NAND flash, which OLPC laptops use as primary storage. While engaged, this protection keeps any process on the machine from altering in any way the system files shipped as part of the OLPC OS build.
644 in less than 512KB, a second copy of the bundle will be stored in the SPI. This

645 secondary copy would be immutable (cannot be reflashed) and used to boot the
This protection may not be disabled without a developer key, explained in Section 8.1.
646 machine in case of the primary BIOS being unbootable. Various factors might
| display = block }}
647 lead to such a state, primarily hard power loss during flashing, such as

648 through the removal of the battery from the machine, or simply a malfunctioning
{{anchor|Chapter 8.4}}{{anchor|P_SF_RUN}}{{anchor|P_SF_RUN: running system file protection}}
649 SPI chip which does not reflash correctly. This section will be updated once it
== P_SF_RUN: Protección de archivos del sistema ejecutandose ==
650 becomes clear whether this protection can be included.

651
Si bien P_SF_CORE protege a los archivos del sistema *almacenados*, P_SF_RUN protege los archivos del sistema en *ejecución* de ser modificados. Siempre que P_SF_RUN se encuentre activo, en cada inicio, el sistema a ejecutar es cargado directamente de los archivos almacenados, los cuales son marcados como de solo-lectura.
652

653
Cuando P_SF_RUN se encuentra desactivado, el procesos de cargado de los archivos del sistema al inicio cambia. En vez de cargar los archivos directamente, una imagen ''COW'' (''copy-on-write'' - copia si escribe) es construída a partir de ellos, y los archivos de _esa_ imagen son inicializados como el sistema en ejecución. La imagen ''COW'' virtualmente no requiere espacio de almacenamiento adicional en la memoria flash NAND hasta que el usuario realiza modificaciones a los archivos del sistema en ejecución, lo que produce un copiado de los archivos antes de ser cambiados. Estas modificaciones son persistentes entre inicios (''booteos''), pero sólo se aplica a las copias ''COW'': los archivos del sistema iniciales permanecen intactos.
== P_SF_CORE: Proteccion del nucleo del sistema de archivos ==
{{ Translated text |
654 8.3. P_SF_CORE: core system file protection
Whereas P_SF_CORE protects the *stored* system files, P_SF_RUN protects the *running* system files from modification. As long as P_SF_RUN is engaged, at every boot, the running system is loaded directly from the stored system files, which are then marked read-only.
655 -----------------------------------------------

656
When P_SF_RUN is disengaged, the system file loading process at boot changes. Instead of loading the stored files directly, a COW (copy on write) image is constructed from them, and system files from _that_ image are initialized as the running system. The COW image uses virtually no additional storage space on the NAND flash until the user makes modifications to her running system files, which causes the affected files to be copied before being changed. These modifications persist between boots, but only apply to the COW copies: the underlying system files remain untouched.
657 The core system file protection disallows modification of the stored system
| display = block }}
658 image on a laptop's NAND flash, which OLPC laptops use as primary storage.

659 While engaged, this protection keeps any process on the machine from altering
Si se reactiva el P_SF_RUN tras su deshabilitación, los archivos utilizados para el inicio del sistema cambian nuevamente; los archivos son cargados a la memoria sin su imagen ''COW'' intermedia, y marcados como de solo lectura.
660 in any way the system files shipped as part of the OLPC OS build.

661
No hay interdependencia entre P_SF_CORE y P_SF_RUN. Si P_SF_CORE está deshabilitado y los archivos del sistema son modificados, pero P_SF_RUN está habilitado, despues del reinicio ninguna modificación al sistema en ejecución sera permitidos, más allá del hecho que los archivos iniciales hayan sido cambiados de la versión original del OS de la OLPC.
662 This protection may not be disabled without a developer key, explained in
{{ Translated text |
663 Section 8.1.
If P_SF_RUN is re-engaged after being disabled, the boot-time loading of system files changes again; the system files are loaded into memory directly with no intermediate COW image, and marked read-only.
664

665
P_SF_CORE and P_SF_RUN do not inter-depend. If P_SF_CORE is disengaged and the stored system files are modified, but P_SF_RUN is engaged, after reboot no modification of the running system will be permitted, despite the fact that the underlying system files have changed from their original version in the OLPC OS build.
666
| display = block }}
== P_SF_RUN: Proteccion del sistema de archivos ejecutandose ==

667 8.4. P_SF_RUN: running system file protection
{{anchor|Chapter 8.5}}{{anchor|P_NET}}{{anchor|P_NET: network policy protection}}
668 ---------------------------------------------
== P_NET: Política de protección de red ==
669

670 Whereas P_SF_CORE protects the *stored* system files, P_SF_RUN protects the
La utilización de la red por parte de un programa puede estar limitado de las siguientes maneras:
671 *running* system files from modification. As long as P_SF_RUN is engaged, at
* Restricción Booleana (si/no) de uso de red
672 every boot, the running system is loaded directly from the stored system files,
* Utilización del ancho de banda por medio de ''token-bucket'' y ráfagas
673 which are then marked read-only.
* Límite a la velocidad de transmisión
674
* Restricciones sobre el destino de los paquetes por nombre, IP y puerto(s)
675 When P_SF_RUN is disengaged, the system file loading process at boot changes.
* Horarios de acceso a la red
676 Instead of loading the stored files directly, a COW (copy on write) image is
* Límite de velocidad por horarios o días
677 constructed from them, and system files from _that_ image are initialized as the
* Restricción como servidor (apertura y escucha de un ''socket''), Booleano y por puerto
678 running system. The COW image uses virtually no additional storage space on the

679 NAND flash until the user makes modifications to her running system files, which
Por defecto, se aplicarán límites razonables de velocidad y volúmen de descarga a todos los programas carentes de firmas. De ser necesario, se pueden aplicar diferentes políticas al tráfico dirigido a la malla o los puntos de acceso (''access points''). Restricciones adicionales podrían ser agregadas a esta lista a medida que completemos la evaluación de los requerimientos de política de red.
680 causes the affected files to be copied before being changed. These modifications
{{ Translated text |
681 persist between boots, but only apply to the COW copies: the underlying system
Each program's network utilization can be constrained in the following ways:
682 files remain untouched.
* Boolean network on/off restriction
683
* token-bucketed bandwidth throttling with burst allowance
684 If P_SF_RUN is re-engaged after being disabled, the boot-time loading of system
* connection rate limiting
685 files changes again; the system files are loaded into memory directly with no
* packet destination restrictions by host name, IP and port(s)
686 intermediate COW image, and marked read-only.
* time-of-day restrictions on network use
687
* data transfer limit by hour or day
688 P_SF_CORE and P_SF_RUN do not inter-depend. If P_SF_CORE is disengaged and the
* server restriction (can bind and listen on a socket), Boolean and per-port
689 stored system files are modified, but P_SF_RUN is engaged, after reboot no

690 modification of the running system will be permitted, despite the fact that the
Reasonable default rate and transfer limits will be imposed on all non-signed programs. If necessary, different policies can apply to mesh and access point traffic. Additional restrictions might be added to this list as we complete our evaluation of network policy requirements.
691 underlying system files have changed from their original version in the OLPC OS
| display = block }}
692 build.

693
{{anchor|Chapter 8.6}}{{anchor|P_NAND_RL}}{{anchor|P_NAND_RL: NAND write/erase protection}}
694
== P_NAND_RL: Protección de escritura/borrado de la NAND ==
695

== P_NET: Politica de proteccion de red ==
Un acelerador tipo ''[http://en.wikipedia.org/wiki/Token_bucket token-bucket]'' con límites de ráfagas será usado por el sistema de archivos JFF2 sobre la memoria flash NAND, que simplemente comenzará a demorar las operaciones de escritura/borrado generadas por un programa en particular después que su balde (''bucket'') se haya agotado. Actualmente se encuentra bajo consideración si una demora tal produzca un impacto exponencial, aunque no se ha tomado ninguna decisión y se esperan resultados de pruebas reales.
696 8.5. P_NET: network policy protection

697 -------------------------------------
Una interface con el núcleo (''kernel'') permitirá el acceso a los niveles de llenado de los baldes (''buckets'') por programa hacia el espacio del usuario, permitiendo así la creación de más políticas aplicables sobre el espacio de usuario, tales como el cerrado de programas cuyos baldes permanezcan agotados durante mucho tiempo. Estas políticas serán mantenidas y ejecutadas por el Servicio de Seguridad del sistema, un programa en el espacio del usuario privilegiado.
698
{{ Translated text |
699 Each program's network utilization can be constrained in the following
A token-bucketed throttle with burst allowance will be in effect for the JFFS2 filesystem used on the NAND flash, which will simply start delaying write/erase operations caused by a particular program after its bucket is drained. It is currently being considered that such a delay behaves as an exponential backoff, though no decision has yet been made, pending some field testing.
700 ways:

701
A kernel interface will expose the per-program bucket fill levels to userspace, allowing the implementation of further userspace policies, such as shutting down programs whose buckets remain drained for too long. These policies will be maintained and enforced by the system Security Service, a privileged userspace program.
702 * Boolean network on/off restriction
| display = block }}
703 * token-bucketed bandwidth throttling with burst allowance

704 * connection rate limiting
{{anchor|Chapter 8.7}}{{anchor|P_NAND_QUOTA}}{{anchor|P_NAND_QUOTA: NAND quota}}
705 * packet destination restrictions by host name, IP and port(s)
706 * time-of-day restrictions on network use
707 * data transfer limit by hour or day
708 * server restriction (can bind and listen on a socket), Boolean and
709 per-port
710
711 Reasonable default rate and transfer limits will be imposed on all non-signed
712 programs. If necessary, different policies can apply to mesh and access point
713 traffic. Additional restrictions might be added to this list as we complete
714 our evaluation of network policy requirements.
715
716
717
== P_NAND_RL: Proteccion contra escritura/borrado de la NAND ==
718 8.6. P_NAND_RL: NAND write/erase protection
719 -------------------------------------------
720
721 A token-bucketed throttle with burst allowance will be in effect for the JFFS2
722 filesystem used on the NAND flash, which will simply start delaying
723 write/erase operations caused by a particular program after its bucket is
724 drained. It is currently being considered that such a delay behaves as an
725 exponential backoff, though no decision has yet been made, pending some field
726 testing.
727
728 A kernel interface will expose the per-program bucket fill levels to
729 userspace, allowing the implementation of further userspace policies, such as
730 shutting down programs whose buckets remain drained for too long. These
731 policies will be maintained and enforced by the system Security Service, a
732 privileged userspace program.
733
734
735
== P_NAND_QUOTA: Cuota de NAND ==
== P_NAND_QUOTA: Cuota de NAND ==

736 8.7. P_NAND_QUOTA: NAND quota
Con el objeto de prevenir ataques de agotamiento de disco, a los programas se les otorga un espacio de borrador (''scratch'') limitado para guardar su configuración y archivos temporales, asi como varios ''caches''. Actualmente, el límite es de 5MiB. Adicionalmente, se impondrán límites sobre los [http://es.wikipedia.org/wiki/Inodo inodes] y [http://es.wikipedia.org/wiki/JFFS2#Modificaciones_respecto_a_JFFS dirents] dentro del espacio de borrador (''scratch''), con valores a determinar.
737 -----------------------------

738
Esto no incluye el espacio para los documentos de usuario creados o manipulados por el programa, que son almacenados por medio del almacén de archivos (''file store''). Dicho almacén de archivos (''file store'') será explicado más adelante.
739 To prevent disk exhaustion attacks, programs are given a limited scratch
{{ Translated text |
740 space in which they can store their configuration and temporary files, such as
741 various caches. Currently, that limit is 5MB. Additionally, limits will be
To prevent disk exhaustion attacks, programs are given a limited scratch space in which they can store their configuration and temporary files, such as various caches. Currently, that limit is 5MB. Additionally, limits will be imposed on inodes and dirents within that scratch space, with values to be determined.

742 imposed on inodes and dirents within that scratch space, with values to be
This does not include space for user documents created or manipulated by the program, which are stored through the file store. The file store is explained in a later section.
743 determined.
| display = block }}
744

745 This does not include space for user documents created or manipulated by the
{{anchor|Chapter 8.8}}{{anchor|P_MIC_CAM}}{{anchor|P_MIC_CAM: microphone and camera protection}}
746 program, which are stored through the file store. The file store is
== P_MIC_CAM: Protección de cámara y micrófono ==
747 explained in a later section.

748
En un primer nivel, la cámara y micrófono incorporados se encuentran protegidos por el hardware: existe un LED al costado de cada uno, que se encenderá (vía hardware, sin control de software) cuando dicho elemento se encuentre activo. Esto provee un indicador simple y obvio de cuando son usados. Su encendido inesperado será una señal ante cualquier intento de espionaje.
749

750
El segundo nivel es que el uso de la cámara y el micrófono requieren la solicitud por parte del programa de un permiso especial al momento de instalación como fue descripto en el [[#Chapter 5|Capítulo 5]]. Este permiso sin embargo no le permite a un programa acceder y prender instantáneamente la cámara o el micrófono. Solamente le permite al programa _preguntarle_ al usuario si puede encender la cámara, el micrófono o ambos.
== P_MIC_CAM: Proteccion de la camara y microfono ==
{{ Translated text |
751 8.8. P_MIC_CAM: microphone and camera protection
At the first level, our built-in camera and microphone are protected by hardware: an LED is present next to each, and is lit (in hardware, without software control) when the respective component is engaged. This provides a very simple and obvious indication of the two being used. The LEDs turning on unexpectedly will immediately tip off the user to potential eavesdropping.
752 ------------------------------------------------

753
Secondly, the use of the camera and microphone require a special permission, requested at install-time as described in Chapter 5, for each program wishing to do so. This permission does not, however, allow a program to instantly turn on the camera and microphone. Instead, it merely lets the program _ask_ the user to allow the camera or microphone (or both) to be turned on.
754 At the first level, our built-in camera and microphone are protected by
| display = block }}
755 hardware: an LED is present next to each, and is lit (in hardware, without

756 software control) when the respective component is engaged. This provides a
Esto quiere decir que cualquier programa benigno que haya sido subvertido pero que no se haya declarado como utilizador de la cámara o el micrófono no puede ser utilizado para activarlos, NI para solicitarle al usuario que lo haga!
757 very simple and obvious indication of the two being used. The LEDs turning on

758 unexpectedly will immediately tip off the user to potential eavesdropping.
Los programas que se hayan declarado a sí mismos como requeridores de dichos privilegios (ej: una aplicación de videoconferencia o [http://es.wikipedia.org/wiki/Voz_sobre_IP VoIP]) pueden instruir al sistema para que le solicite al usuario su permiso de activar la cámara o el micrófono, y si la solicitud es otorgada, el programa tendrá permiso de manipular el componente por un tiempo limitado, ej: 30 minutos. Transcurrido dicho plazo de tiempo, se le deberá solicitar nuevamente al usuario su permiso.
759
{{ Translated text |
760 Secondly, the use of the camera and microphone require a special permission,
This means that any benign programs which are taken over but haven't declared themselves as needing the camera or microphone cannot be used neither to turn on either, NOR to ask the user to do so!
761 requested at install-time as described in Chapter 5, for each program

762 wishing to do so. This permission does not, however, allow a program to
Programs which have declared themselves as requiring those privileges (e.g. a VOIP or videoconferencing app) can instruct the system to ask the user for permission to enable the camera and microphone components, and if the request is granted, the program is granted a timed capability to manipulate the components, e.g. for 30 minutes. After that, the user will be asked for permission again.
763 instantly turn on the camera and microphone. Instead, it merely lets the
| display = block }}
764 program _ask_ the user to allow the camera or microphone (or both) to be

765 turned on.
Como fue mencionado en el [[#Chapter 5|Capítulo 5]], los programas firmados criptográficamente por una autoridad de confianza estarán exentos de necesitar el pedir permiso para manipular los componentes, pero dada la presencia de los LEDs indicadores de su estado, el potencial para su abuso es bastante bajo.
766
{{ Translated text |
767 This means that any benign programs which are taken over but haven't
As mentioned in Chapter 5, programs cryptographically signed by a trusted authority will be exempt from having to ask permission to manipulate the components, but because of the LEDs which indicate their status, the potential for abuse is rather low.
768 declared themselves as needing the camera or microphone cannot be used
| display = block }}
769 neither to turn on either, NOR to ask the user to do so!

770
{{anchor|Chapter 8.9}}{{anchor|P_CPU_RL}}{{anchor|P_CPU_RL: CPU rate limiting}}
771 Programs which have declared themselves as requiring those privileges (e.g.
== P_CPU_RL: Limitando la CPU ==
772 a VOIP or videoconferencing app) can instruct the system to ask the user for

773 permission to enable the camera and microphone components, and if the request
Los programas activos en primera plana (''foreground'') pueden utilizar toda la potencia de la ''CPU''. Sin embargo, los programas en el fondo (''background''), no pueden usar mas que una cantidad fija&mdash;actualmente estamos pensando en usar un 10%&mdash;a no ser que tengan un permiso especial por parte del usuario.
774 is granted, the program is granted a timed capability to manipulate the

775 components, e.g. for 30 minutes. After that, the user will be asked for
La IU de Sugar en las laptops XO no soportan ventanas superpuestas: solo ventanas de aplicaciones maximizadas son soportadas. Cuando nos referimos a la ejecución en primer plano o fondo, nos estamos refiriendo a los programas que estan, o no, mostrando ventanas en la pantalla en un dado momento.
776 permission again.
{{ Translated text |
777
Foreground programs may use all of the machine's CPU power. Background programs, however, may use no more than a fixed amount -- currently we're looking to use 10% -- unless given a special permission by the user.
778 As mentioned in Chapter 5, programs cryptographically signed by a

779 trusted authority will be exempt from having to ask permission to manipulate
The Sugar UI environment on the XO laptops does not support overlapping windows: only maximized application windows are supported. When we talk about foreground and background execution, we are referring to programs that are, or are not, currently displaying windows on the screen.
780 the components, but because of the LEDs which indicate their status, the
| display = block }}
781 potential for abuse is rather low.

782
{{anchor|Chapter 8.10}}{{anchor|P_RTC}}{{anchor|P_RTC: real time clock protection}}
783
== P_RTC: Protección del reloj de tiempo real ==
784

== P_CPU_RL: Limitando el uso de la CPU ==
Un desplazamiento de tiempo relativo al ''RTC'' (''real time clock'' - reloj de tiempo real) es mantenido para cada programa en ejecución, y se le permite al programa cambiar dicho desplazamiento de forma arbitraria. Esto satisface las necesidades de ciertos programas de cambiar el reloj del sistema que usan (ya tenemos un programa de música que debe sincronizarse con un margen de 10ms con cualquier otra máquina con la cual esten tocando música) evitando impactar en otros programas del sistema.
785 8.9. P_CPU_RL: CPU rate limiting
{{ Translated text |
786 --------------------------------
A time offset from the RTC is maintained for each running program, and the program is allowed to change the offset arbitrarily. This fulfills the need of certain programs to change the system time they use (we already have a music program that must synchronize to within 10ms with any machines with which it co-plays a tune) while not impacting other programs on the system.
787
| display = block }}
788 Foreground programs may use all of the machine's CPU power. Background

789 programs, however, may use no more than a fixed amount -- currently we're
{{anchor|Chapter 8.11}}{{anchor|P_DSP_BG}}{{anchor|P_DSP_BG: background sound permission}}
790 looking to use 10% -- unless given a special permission by the user.
791
792 The Sugar UI environment on the XO laptops does not support overlapping
793 windows: only maximized application windows are supported. When we talk about
794 foreground and background execution, we are referring to programs that are, or
795 are not, currently displaying windows on the screen.
796
797
798
== P_RTC: Proteccion del reloj de tiempo real ==
799 8.10. P_RTC: real time clock protection
800 ---------------------------------------
801
802 A time offset from the RTC is maintained for each running program, and the
803 program is allowed to change the offset arbitrarily. This fulfills the need
804 of certain programs to change the system time they use (we already have a
805 music program that must synchronize to within 10ms with any machines with
806 which it co-plays a tune) while not impacting other programs on the system.
807
808
809
== P_DSP_BG: Permiso de sonido de fondo ==
== P_DSP_BG: Permiso de sonido de fondo ==

810 8.11. P_DSP_BG: background sound permission
Este es un permiso, solicitable al momento de instalación, que habilita al programa a generar audio cuando no se encuentra en primer plano (''foreground''). Su objetivo es permitir que los programas benignos sean inmunes a ser utilizados para generar sonidos molestos o embarazosos en el caso de ser subvertidos.
811 -------------------------------------------
{{ Translated text |
812
813 This is a permission, requestable at install-time, which lets the program
This is a permission, requestable at install-time, which lets the program play audio while it isn't in the foreground. Its purpose is to make benign programs immune to being used to play annoying or embarrassing loud sounds if taken over.
| display = block }}
814 play audio while it isn't in the foreground. Its purpose is to make benign

815 programs immune to being used to play annoying or embarrassing loud sounds
{{anchor|Chapter 8.12}}{{anchor|P_X}}{{anchor|P_X: X window system protection}}
816 if taken over.

817
== P_X: Protección del sistema de ventanas X ==
818

819
Cuando es asignado manualmente a un programa por medio de la interfaz gráfica de seguridad, éste permiso habilita a un programa a enviar eventos de ratón sintéticos a otro programa. Su objetivo es permitir el uso de software de accesibilidad como un teclado-en-pantalla. Este permiso NO es solicitable al momento de instalación, y por lo tanto deber ser manualmente otorgado por el usuario por medio de la interz gráfica, a no ser que el software que quiera usarlo este firmado criptográficamente por una autoridad de confianza.
== P_X: Proteccion del sistema de ventanas X ==

820 8.12. P_X: X window system protection
Sin este permiso, los programas no pueden espiar o simular los eventos de otros, lo cual inhabilita software de grabado de teclado (''key logging'') o ataques basados en una manipulación sofisticada de eventos sintéticos, donde un software malicioso actúa como un control remoto para algún otro programa.
821 -------------------------------------
{{ Translated text |
822
When manually assigned to a program by the user through a graphical security interface, this permission lets a program send synthetic mouse X events to another program. Its purpose is to enable the use of accessibility software such as an on-screen keyboard. The permission is NOT requestable at install-time, and thus must be manually assigned by the user through a graphical interface, unless the software wishing to use it is cryptographically signed by a trusted authority.
823 When manually assigned to a program by the user through a graphical

824 security interface, this permission lets a program send synthetic mouse
Without this permission, programs cannot eavesdrop on or fake one another's events, which disables key logging software or sophisticated synthetic event manipulation attacks, where malicious software acts as a remote control for some other running program.
825 X events to another program. Its purpose is to enable the use of
| display = block }}
826 accessibility software such as an on-screen keyboard. The permission is NOT

827 requestable at install-time, and thus must be manually assigned by the user
{{anchor|Chapter 8.13}}{{anchor|P_IDENT}}{{anchor|P_IDENT: identity service}}
828 through a graphical interface, unless the software wishing to use it is
829 cryptographically signed by a trusted authority.
830
831 Without this permission, programs cannot eavesdrop on or fake one another's
832 events, which disables key logging software or sophisticated synthetic event
833 manipulation attacks, where malicious software acts as a remote control for
834 some other running program.
835
836
837
== P_IDENT: Servicio de identidad ==
== P_IDENT: Servicio de identidad ==

838 8.13. P_IDENT: identity service
El servicio de identidad es el responsable de generar el par de llaves ECC durante el primer inicio, mantener al par seguro, y responder a los pedidos de inicio de sesiones firmadas o encriptadas con otras máquinas en la red.
839 -------------------------------

840
Con el uso del servicio de identidad, todas las interacciones o comunicaciones entre pares (e-mails, mensajes instantáneos, y similares) pueden ser firmados criptográficamente para mantener su integridad aún si son ruteados a través de pares potencialmente maliciosos en la malla, y también puede ser encriptado en aquellos países que no represente un problema legal.
841 The identity service is responsible for generating an ECC key pair at first
{{ Translated text |
842 boot, keeping the key pair secure, and responding to requests to initiate
843 signed or encrypted sessions with other networked machines.
The identity service is responsible for generating an ECC key pair at first boot, keeping the key pair secure, and responding to requests to initiate signed or encrypted sessions with other networked machines.

844
845 With the use of the identity service, all digital peer interactions or
With the use of the identity service, all digital peer interactions or communication (e-mails, instant messages, and so forth) can be cryptographically signed to maintain integrity even as they're routed through potentially malicious peers on the mesh, and may also be encrypted in countries where this does not present a legal problem.
| display = block }}
846 communication (e-mails, instant messages, and so forth) can be

847 cryptographically signed to maintain integrity even as they're routed through
{{anchor|Chapter 8.14"}}{{anchor|P_SANDBOX}}{{anchor|P_SANDBOX: program jails}}
848 potentially malicious peers on the mesh, and may also be encrypted in countries
== P_SANDBOX: Cárceles de programas ==
849 where this does not present a legal problem.

850
Un programa en la XO comienza en un [http://en.wikipedia.org/wiki/Chroot chroot] fortificado, similar a una [http://en.wikipedia.org/wiki/FreeBSD_jail cárcel BSD], donde la raíz visible del sistema de archivos es el su propio espacio de borrador (''scratch''). Usualmente no tiene acceso a las rutas de acceso del sistema tales como <tt>/proc</tt> o <tt>/sys</tt>, no puede ver otros programas en el sistema o sus espacios de borrador (''scratch''). No puede acceder a los documentos del usuario directamente, sino a traves del servicio de almacén de archivos (''file store service''), explicado en la siguiente sección.
851

852
El espacio de borrador (''scratch'') de cada programa posee tres directorios escribibles, llamados '<tt>tmp</tt>', '<tt>conf</tt>', y '<tt>data</tt>'. El programa es libre de usarlos para archivos temporales, de configuración, y datos (recursos) respectivamente. El resto del espacio de borrador (''scratch'') es inmutable; el programa no puede modificar sus binarios o archivos de recursos principales. Este modelo asegura que un programa pueda ser restaurado a su instalación de base por medio de la eliminación del contenido de esos tres directorios escribibles, y que pueda ser desinstalado en su totalidad eliminando su directorio.
== P_SANDBOX: Carceles / jaulas de programas ==
{{ Translated text |
853 8.14. P_SANDBOX: program jails
A program on the XO starts in a fortified chroot, akin to a BSD jail, where its visible filesystem root is only its own constrained scratch space. It normally has no access to system paths such as /proc or /sys, cannot see other programs on the system or their scratch spaces, and only the libraries it needs are mapped into its scratch space. It cannot access user documents directly, but only through the file store service, explained in the next section.
854 ----------------------------------

855
Every program scratch space has three writable directories, called 'tmp', 'conf', and 'data'. The program is free to use these for temporary, configuration, and data (resource) files, respectively. The rest of the scratch space is immutable; the program may not modify its binaries or core resource files. This model ensures that a program may be restored to its base installation state by emptying the contents of the three writable directories, and that it can be completely uninstalled by removing its bundle (scratch space) directory.
856 A program on the XO starts in a fortified chroot, akin to a BSD jail,
| display = block }}
857 where its visible filesystem root is only its own constrained scratch space. It

858 normally has no access to system paths such as /proc or /sys, cannot see other
{{anchor|Chapter 8.15}}{{anchor|P_DOCUMENT}}{{anchor|P_DOCUMENT: file store service}}
859 programs on the system or their scratch spaces, and only the libraries it needs
860 are mapped into its scratch space. It cannot access user documents directly,
861 but only through the file store service, explained in the next section.
862
863 Every program scratch space has three writable directories, called 'tmp',
864 'conf', and 'data'. The program is free to use these for temporary,
865 configuration, and data (resource) files, respectively. The rest of the scratch
866 space is immutable; the program may not modify its binaries or core
867 resource files. This model ensures that a program may be restored to its
868 base installation state by emptying the contents of the three writable
869 directories, and that it can be completely uninstalled by removing its bundle
870 (scratch space) directory.
871
872
873
== P_DOCUMENT: Servicio de almacenamiento de archivos ==
== P_DOCUMENT: Servicio de almacenamiento de archivos ==

874 8.15. P_DOCUMENT: file store service
A diferencia de las máquinas tradicionales, los documentos del usuario en las laptops XO no son guardados directamente en el sistema de archivos. En su lugar, son leídos y guardados por medio de un servicio de almacenamiento de archivos, que provee una interfaz orientada-a-objetos a los documentos del usuario. El diseño, en términos amplios y generales, es similar a [http://es.wikipedia.org/wiki/WinFS WinFS] de Microsoft, ya que el almacén permite una rica asociación de metadata manteniendo la semántica de lectura y escritura (''<tt>read()/write()</tt>'') tradicionales de UNIX para la manipulación del contenido del archivo.
875 ------------------------------------

876
Los programas en la XO no pueden hacer uso de la función <tt>open()</tt> (abrir) para abrir arbitrariamente un documento del usuario en el sistema, ni inspeccionar la lista de documentos disponibles, ej: examinando los contenidos de un directorio. En su lugar, cuando un programa desea abrir un documento del usuario, debe solicitarle al sistema que le presente al usuario un dialogo de 'apertura de archivo'. Una versión copia-si-escribe (''copy-on-write'') del archivo así seleccionado simplemente "aparecerá" en el espacio de borrador (''scratch'') del programa junto con un mensaje informandole de su ruta de acceso dentro de dicho espacio de borrador (''scratch'').
877 Unlike with traditional machines, user documents on the XO laptop are not
{{ Translated text |
878 stored directly on the filesystem. Instead, they are read and stored through
Unlike with traditional machines, user documents on the XO laptop are not stored directly on the filesystem. Instead, they are read and stored through the file store service, which provides an object-oriented interface to user documents. Similar in very broad terms to the Microsoft WinFS design, the file store allows rich metadata association while maintaining traditional UNIX read()/write() semantics for actual file content manipulation.
879 the file store service, which provides an object-oriented interface to user

880 documents. Similar in very broad terms to the Microsoft WinFS design, the file
Programs on the XO may not use the open() call to arbitrarily open user documents in the system, nor can they introspect the list of available documents, e.g. through listing directory contents. Instead, when a program wishes to open a user document, it asks the system to present the user with a 'file open' dialog. A copy-on-write version of the file that the user selects is also mapped into this scratch space -- in effect, the file just "appears", along with a message informing the program of the file's path within the scratch space.
881 store allows rich metadata association while maintaining traditional UNIX
| display = block }}
882 read()/write() semantics for actual file content manipulation.

883
Unix permite el pasaje de [http://es.wikipedia.org/wiki/Descriptor_de_fichero descriptores de archivos] (''fds - file descriptors'') a traves de ''domain sockets'' de Unix, con lo cual una alternativa de P_DOCUMENT sería pasar el descriptor (<tt>''fd''</tt>) de dicho archivo. Hemos decidido no usar dicha alternativa ya que la comunicación con el almacén de archivos no se lleva a cabo directamente sobre ''domain sockets'' de Unix, sino por medio de los mecanismos del [http://es.wikipedia.org/wiki/D-BUS D-BUS] IPC, y porque la manipulación directa de los descriptores (<tt>''fds''</tt>) puede ser complicada en lenguajes de alto nivel.
884 Programs on the XO may not use the open() call to arbitrarily open user

885 documents in the system, nor can they introspect the list of available
Los programas benignos no son afectados negativamente por esta necesidad de usar al almacén de archivos para acceder a los documentos, particularmente porque en general no les interesa mostrar sus propios diálogos de apertura de archivos (con la rara excepción de aquellos que los especializan ej: permitir una vista en miniatura; por el momento, no esta siendo considerado este caso de uso).
886 documents, e.g. through listing directory contents. Instead, when a program

887 wishes to open a user document, it asks the system to present the user with a
Sin embargo, los programas malignos, pierden una importante capacidad de violar la privacidad del usuario o dañar sus datos, ya que todo acceso a los documentos requiere del consentimiento explícito por parte del usuario.
888 'file open' dialog. A copy-on-write version of the file that the user selects
{{ Translated text |
889 is also mapped into this scratch space -- in effect, the file just "appears",
Unix supports the passing of file descriptors (fds) through Unix domain sockets, so an alternative implementation of P_DOCUMENT would merely pass in the fd of the file in question to the calling program. We have elected not to pursue this approach because communication with the file store service does not take place directly over Unix domain sockets, but over the D-BUS IPC mechanism, and because dealing with raw fds can be a hassle in higher-level languages.
890 along with a message informing the program of the file's path within the

891 scratch space.
Benign programs are not adversely impacted by the need to use the file store for document access, because they generally do not care about rendering their own file open dialogs (with the rare exception of programs which create custom dialogs to e.g. offer built-in file previews; for the time being, we are not going to support this use case).
892

893 Unix supports the passing of file descriptors (fds) through Unix domain
Malicious programs, however, lose a tremendous amount of ability to violate the user's privacy or damage her data, because all document access requires explicit assent by the user.
894 sockets, so an alternative implementation of P_DOCUMENT would merely pass in
| display = block }}
895 the fd of the file in question to the calling program. We have elected not to

896 pursue this approach because communication with the file store service does not
{{anchor|Chapter 8.16}}{{anchor|P_DOCUMENT_RO}}
897 take place directly over Unix domain sockets, but over the D-BUS IPC mechanism,
898 and because dealing with raw fds can be a hassle in higher-level languages.
899
900 Benign programs are not adversely impacted by the need to use the file store
901 for document access, because they generally do not care about rendering their
902 own file open dialogs (with the rare exception of programs which create
903 custom dialogs to e.g. offer built-in file previews; for the time being, we
904 are not going to support this use case).
905
906 Malicious programs, however, lose a tremendous amount of ability to violate
907 the user's privacy or damage her data, because all document access requires
908 explicit assent by the user.
909
910
911
== P_DOCUMENT_RO ==
== P_DOCUMENT_RO ==

912 8.16. P_DOCUMENT_RO
Ciertos tipos de software, como un programa de visualizacion de fotos, necesita el acceso a todos los documentos de un cierto tipo (ej: imágenes) con el fin de cumplir su función. Esto entra en conflicto directo con la protección P_DOCUMENT que requiere el consentimiento del usuario para cada documento a abrir&mdash;en este caso, cada foto.
913 -------------------

914
Para resolver este dilema, nos debemos preguntar: "de que estamos tratando de proteger al usuario?" La respuesta, en este caso, es de un programa malicioso que solicita el permiso de leer todas las imagenes, o todos los archivos de texto, o todos los e-mails, y despues enviar dichos documentos por la red a un atacante o su publicación, vulnerando seriamente la privacidad del usuario.
915 Certain kinds of software, such as photo viewing programs, need access to
{{ Translated text |
916 all documents of a certain kind (e.g. images) to fulfill their desired
917 function. This is in direct opposition with the P_DOCUMENT protection which
Certain kinds of software, such as photo viewing programs, need access to all documents of a certain kind (e.g. images) to fulfill their desired function. This is in direct opposition with the P_DOCUMENT protection which requires user consent for each document being opened -- in this case, each photo.

918 requires user consent for each document being opened -- in this case, each
To resolve the quandary, we must ask ourselves: "from what are we trying to protect the user?". The answer, here, is a malicious program which requests permission to read all images, or all text files, or all e-mails, and then sends those documents over the network to an attacker or posts them publicly, seriously breaching the user's privacy.
919 photo.
| display = block }}
920

921 To resolve the quandary, we must ask ourselves: "from what are we trying to
Resolvemos esto permitiendo que un programa solicite permisos de solo-lectura para un tipo de documento (ej: imagen, audio, texto, e-mail) durante el proceso de instalación, pero haciendo dicho permiso (P_DOCUMENT_RO) mutuamente excluyente con el solicitar cualquier tipo de acceso a la red. En otras palabras, un programa de visualización de fotos, normalmente no tiene ninguna necesidad o interés en conectarse a Internet.
922 protect the user?". The answer, here, is a malicious program which requests

923 permission to read all images, or all text files, or all e-mails, and then
Como con otros permisos, el usuario puede habilitar el permiso de red a un dado programa que haya solicitado P_DOCUMENT_RO durante su instalación, evitando así la exclusión mutua.
924 sends those documents over the network to an attacker or posts them publicly,
{{ Translated text |
925 seriously breaching the user's privacy.
We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet.
926

927 We solve this by allowing programs to request read-only permissions for one
As with other permissions, the user may assign the network permission to a program which requested P_DOCUMENT_RO at install, bypassing the mutual exclusion.
928 type of document (e.g. image, audio, text, e-mail) at installation time, but
| display = block }}
929 making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any

930 network access at all. A photo viewing program, in other words, normally
{{anchor|Chapter 8.17}}{{anchor|P_DOCUMENT_RL}}{{anchor|P_DOCUMENT_RL: file store rate limiting}}
931 has no business connecting to the Internet.
932
933 As with other permissions, the user may assign the network permission to a
934 program which requested P_DOCUMENT_RO at install, bypassing the mutual
935 exclusion.
936
937
938
== P_DOCUMENT_RL: Limitando el ritmo de almacenamiento de archivos ==
== P_DOCUMENT_RL: Limitando el ritmo de almacenamiento de archivos ==

939 8.17. P_DOCUMENT_RL: file store rate limiting
El almacén de archivos (''file store'') no permite a los programas guardar nuevos archivos o nuevas versiones de archivos viejos con una frecuencia mayor a un dado valor, ej: una vez cada 30 segundos.
940 ---------------------------------------------
{{ Translated text |
941
942 The file store does not permit programs to store new files or new versions
The file store does not permit programs to store new files or new versions of old files with a frequency higher than a certain preset, e.g. once every 30 seconds.
| display = block }}
943 of old files with a frequency higher than a certain preset, e.g. once every 30

944 seconds.
{{anchor|Chapter 8.18}}{{anchor|P_DOCUMENT_BACKUP}}{{anchor|P_DOCUMENT_BACKUP: file store backup service}}
945
946
947
== P_DOCUMENT_BACKUP: Servicio de respaldo de archivos ==
== P_DOCUMENT_BACKUP: Servicio de respaldo de archivos ==

948 8.18. P_DOCUMENT_BACKUP: file store backup service
Cuando se este dentro del alcance de servidores que se anuncien a sí mismos como oferentes del servicio de respaldo (''backup''), la laptop realizará automáticamente las copias de respaldo incrementales de los documentos del usuario que podrán ser recuperados con posterioridad. Dado el deseo de evitar que un chico tenga que generar una nueva identidad digital si alguna vez su laptop es extraviada, robada o destruida, por defecto el par de llaves ECC del chico tambien son copiadas al servidor de respaldo. Dado que la llave privada de un chico normalmente no está protegida con una palabra clave (''password''), robando el servidor primario de respaldo (normalmente el servidor escolar) le ofrece al ladrón la habilidad de suplantar a cualquier chico en el sistema.
949 --------------------------------------------------

950
Por el momento, consideramos que esto es un riesgo aceptable. Aunque debería ser mencionado que la llave privada sólo será copiada al servidor de respaldo primario&mdash;usualmente en la escuela&mdash;y no a cualquier servidor que se anuncia como proveedor del servicio de respaldo. Aún más, en cualquiera de los servidores de respaldo no-primarios, solamente se guardarán versiones incrementales encriptadas.
951 When in range of servers that advertise themselves as offering a backup
{{ Translated text |
952 service, the laptop will automatically perform incremental backups of user
When in range of servers that advertise themselves as offering a backup service, the laptop will automatically perform incremental backups of user documents which it can later retrieve. Because of the desire to avoid having to ask children to generate a new digital identity if their laptop is ever lost, stolen or broken, by default the child's ECC keypair is also backed up to the server. Given that a child's private key normally has no password protection, stealing the primary backup server (normally the school server) offers the thief the ability to impersonate any child in the system.
953 documents which it can later retrieve. Because of the desire to avoid having to

954 ask children to generate a new digital identity if their laptop is ever lost,
For now, we deem this an acceptable risk. We should also mention that the private key will only be backed up to the primary backup server -- usually in the school -- and not any server that advertises itself as providing backup service. Furthermore, for all non-primary backup servers, only encrypted version of the incremental backups will be stored.
955 stolen or broken, by default the child's ECC keypair is also backed up to the
| display = block }}
956 server. Given that a child's private key normally has no password protection,

957 stealing the primary backup server (normally the school server) offers the
{{anchor|Chapter 8.19}}{{anchor|P_THEFT}}{{anchor|P_THEFT: anti-theft protection}}
958 thief the ability to impersonate any child in the system.
== P_THEFT: Protección anti-robo ==
959

960 For now, we deem this an acceptable risk. We should also mention that the
El proyecto de la OLPC ha recibido solicitudes muy firmes por parte de algunos países considerando unirse al programa para la inclusión de un poderoso servicio anti-robo a fin de disuadir a la mayoría de los ladrones.
961 private key will only be backed up to the primary backup server -- usually in

962 the school -- and not any server that advertises itself as providing backup
Proveemos dicho servicio para que los países interesados puedan habilitarlo en sus laptops. Funciona por medio de la ejecución de un proceso privilegiado que no puede ser deshabilitado o finalizado aún por el administrador (''root''), un demonio (''daemon'') anti-robo que al detectar un acceso a Internet, realiza una llamada-a-casa (''call-home'')&mdash;no más de una vez al día&mdash;a los servidores anti-robo nacionales. Al hacerlo, es capaz de usar al ''[http://es.wikipedia.org/wiki/Network_Time_Protocol NTP]'' (''network time protocol''&mdash;protocolo de tiempo de red) de manera segura para ajustar el reloj de tiempo real (''RTC - real time clock'') de la máquina a la hora actual, y despues obtener un plazo criptográfico para seguir corriendo durante una dada cantidad de tiempo, ej: 21 días. La duración del plazo es controlada por cada país.
963 service. Furthermore, for all non-primary backup servers, only encrypted
{{ Translated text |
964 version of the incremental backups will be stored.
The OLPC project has received very strong requests from certain countries considering joining the program to provide a powerful anti-theft service that would act as a theft deterrent against most thieves.
965

966
We provide such a service for interested countries to enable on the laptops. It works by running, as a privileged process that cannot be disabled or terminated even by the root user, an anti-theft daemon which detects Internet access, and performs a call-home request -- no more than once a day -- to the country's anti-theft servers. In so doing, it is able to securely use NTP to set the machine RTC to the current time, and then obtain a cryptographic lease to keep running for some amount of time, e.g. 21 days. The lease duration is controlled by each country.
967
| display = block }}
== P_THEFT: Proteccion anti-robo ==

968 8.19. P_THEFT: anti-theft protection
La tupla (NS, UUID) de una laptop robada será reportada al cuerpo responsable del servicio anti-robo encargado del proyecto de la OLPC en el país. La laptop será así marcada como robada en la base de datos central nacional.
969 ------------------------------------

970
Un ladrón puede intentar varias cosas con la laptop: usarla para conectarse a la Internet, aislarla de cualquier red e utilizarla de modo aislado, o usar sus componentes como piezas.
971 The OLPC project has received very strong requests from certain countries
{{ Translated text |
972 considering joining the program to provide a powerful anti-theft service that
A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC
973 would act as a theft deterrent against most thieves.
oversight body in charge of the anti-theft service. The laptop will be marked
974
stolen in the country's master database.
975 We provide such a service for interested countries to enable on the laptops. It

976 works by running, as a privileged process that cannot be disabled or
A thief might do several things with a laptop: use it to connect to the
977 terminated even by the root user, an anti-theft daemon which detects Internet
Internet, remove it from any networks and attempt to use it as a standalone
978 access, and performs a call-home request -- no more than once a day -- to the
machine, or take it apart for parts.
979 country's anti-theft servers. In so doing, it is able to securely use NTP to
| display = block }}
980 set the machine RTC to the current time, and then obtain a cryptographic lease

981 to keep running for some amount of time, e.g. 21 days. The lease duration is
En el primer caso, el ''daemon'' anti-robo se enteraría que la laptop ha sido robada tan pronto como se conecte a Internet, y llevará a cabo un apagado 'duro' (''hard shutdown'') y bloqueará la máquina de modo tal de necesitar una activación, mencionada anteriormente, para volver a funcionar.
982 controlled by each country.

983
No esperamos que las máquinas sean un blanco apetecible para la reventa de partes. Exceptuando la pantalla especial, todas las otras partes de las laptops XO se encuentran soldadas a la placa madre (''motherboard'').
984 A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC
{{ Translated text |
985 oversight body in charge of the anti-theft service. The laptop will be marked
In the former case, the anti-theft daemon would learn that the laptop is stolen
986 stolen in the country's master database.
as soon as it's connected to the Internet, and would perform a hard shutdown
987
and lock the machine such that it requires activation, described previously, to
988 A thief might do several things with a laptop: use it to connect to the
function.
989 Internet, remove it from any networks and attempt to use it as a standalone

990 machine, or take it apart for parts.
We do not expect the machines will be an appealing target for part resale. Save
991
for the custom display, all valuable parts of the XO laptops are soldered onto
992 In the former case, the anti-theft daemon would learn that the laptop is stolen
the motherboard.
993 as soon as it's connected to the Internet, and would perform a hard shutdown
| display = block }}
994 and lock the machine such that it requires activation, described previously, to

995 function.
Considerando el caso donde una máquina robada es usada como una computadora personal pero sin estar conectada a Internet, el ''daemon'' anti-robo procederá a apagar y bloquear la máquina si su plazo criptográfico alguna vez expirase. En otras palabras, si el país opera con plazos de 21 días, una laptop normal, no-robada, tendrá su plazo renovado por 21 días cada día que se conecte a Internet. Pero si la máquina no se conecta a Internet durante 21 días, se apagará y bloqueará.
996

997 We do not expect the machines will be an appealing target for part resale. Save
Dado que esto podría representar ciertos problemas en algunos países con un acceso intermitente a Internet, los plazos pueden ser bastante largos (siguen siendo una disuasión efectiva aún con una duración de tres meses), o pueden ser prolongados por medio de la conexion de un disco USB al servidor de activación. Por ejemplo, un país puede otorgar plazos de tres semanas, pero si una escuela sufriese un desperfecto en su antena satelital, el cuerpo responsable del país de la OLPC puede enviar por correo un disco USB al responsable de la distribución en la escuela, el cual una vez conectado al servidor escolar, y de un modo transparente, extiende el plazo para cada laptop referenciada por un dado período de tiempo.
998 for the custom display, all valuable parts of the XO laptops are soldered onto
{{ Translated text |
999 the motherboard.
To address the case where a stolen machine is used as a personal computer but
1000
not connected to the Internet, the anti-theft daemon will shut down and lock
1001 To address the case where a stolen machine is used as a personal computer but
the machine if its cryptographic lease ever expires. In other words, if the
1002 not connected to the Internet, the anti-theft daemon will shut down and lock
country operates with 21-day leases, a normal, non-stolen laptop will get the
1003 the machine if its cryptographic lease ever expires. In other words, if the
lease extended by 21 days each day it connects to the Internet. But if the
1004 country operates with 21-day leases, a normal, non-stolen laptop will get the
machine does not connect to the Internet for 21 days, it will shut down and
1005 lease extended by 21 days each day it connects to the Internet. But if the
lock.
1006 machine does not connect to the Internet for 21 days, it will shut down and

1007 lock.
Since this might present a problem in some countries due to intermittent
1008
Internet access, the leases can either be made to last rather long (they're
1009 Since this might present a problem in some countries due to intermittent
still an effective theft deterrent even with a 3 month duration), or they can
1010 Internet access, the leases can either be made to last rather long (they're
be manually extended by connecting a USB drive to the activation server. For
1011 still an effective theft deterrent even with a 3 month duration), or they can
instance, a country may issue 3-week leases, but if a school has a satellite
1012 be manually extended by connecting a USB drive to the activation server. For
1013 instance, a country may issue 3-week leases, but if a school has a satellite
dish failure, the country's OLPC oversight body may mail a USB drive to the
school handler, which when connected to the school server, transparently
1014 dish failure, the country's OLPC oversight body may mail a USB drive to the
extends the lease of each referenced laptop for some period of time.
1015 school handler, which when connected to the school server, transparently
| display = block }}
1016 extends the lease of each referenced laptop for some period of time.

1017
El sistema anti-robo no puede ser evitado mientras el P_SF_CORE este habilitado (y su deshabilitación requiere de una llave de desarrollador). Esto, de hecho, quiere decir que un chico es libre de realizar cualquier modificación sobre su espacio de usuario en su máquina (por medio de la desactivación del P_SF_RUN sin necesidad de la llave de desarrollador), pero no puede cambiar el núcleo (''kernel'') en ejecución sin solicitar la llave. El proceso de entrega de llaves tiene incorporado una demora de 14 días con el objeto de permitir demoras en el reporte de robos a traves del sistema, y sólo es emitida si la máquina no ha sido reportada como robada al finalizar dicho periodo de tiempo.
1018 The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and
{{ Translated text |
1019 disabling it requires a developer key). This, in effect, means that a child is
The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and
1020 free to do any modification to her machine's userspace (by disabling P_SF_RUN
1021 without a developer key), but cannot change the running kernel without
disabling it requires a developer key). This, in effect, means that a child is
free to do any modification to her machine's userspace (by disabling P_SF_RUN
1022 requesting the key. The key-issuing process incorporates a 14-day delay to
without a developer key), but cannot change the running kernel without
1023 allow for a slow theft report to percolate up through the system, and is only
requesting the key. The key-issuing process incorporates a 14-day delay to
1024 issued if the machine is not reported stolen at the end of that period of time.
allow for a slow theft report to percolate up through the system, and is only
1025
issued if the machine is not reported stolen at the end of that period of time.
1026
| display = block }}
1027

== P_SERVER_AUTH: Autentificacion transparente y segura a un servidor autorizado ==
1028 8.21. P_SERVER_AUTH: transparent strong authentication to trusted server
{{anchor|Chapter 8.20}}{{anchor|P_SERVER_AUTH}}{{anchor|P_SERVER_AUTH: transparent strong authentication to trusted server}}
== P_SERVER_AUTH: Autentificación transparente y segura a un servidor autorizado ==
1029 ------------------------------------------------------------------------

1030
Cuando se este dentro del alcance de un servidor autorizado (ej: uno provisto por la OLPC o el país), la laptop puede responder de manera segura a un desafío de autentificación (''authentication challenge'') con su tupla (NS, UUID). Además de servirle a la escuela como un mecanismo de control de acceso a la red&mdash;sabemos de ciertas escuelas, por ejemplo, no desean proveer acceso a Internet a sus ex-alumnos, solamente a los actuales&mdash;esta autentificación puede desbloquear ciertos servicios extras como copias de respaldo y el acceso servicios de identidad digital descentralizados tales como [http://es.wikipedia.org/wiki/OpenID OpenID].
1031 When in wireless range of a trusted server (e.g. one provided by OLPC or the

1032 country), the laptop can securely respond to an authentication challenge with
[http://es.wikipedia.org/wiki/OpenID OpenID] es particularmente interesante para la OLPC, dado que puede ser usado para perpetuar un acceso sin palabras claves aún con sitios que normalmente requieren autentificación, siempre y cuando soporte OpenID. El modo de uso actualmente más común entre los proveedores del servicio de OpenID es el de requerir una autentificación al usuario por medio de una palabra clave. Con un proveedor de servicio OpenID corriendo en el servidor escolar (o algún otro servidor de confianza), los ''logins'' a sitios que funcionan con OpenID simplemente ocurrirán de modo transparente, dado que la máquina del chico ya ha sido autenticada en el fondo por P_SERVER_AUTH.
1033 its (SN, UUID) tuple. In addition to serving as a means for the school to
{{ Translated text |
1034 exercise network access control -- we know about some schools, for instance,
When in wireless range of a trusted server (e.g. one provided by OLPC or the
1035 that do not wish to provide Internet access to alumni, but only current
country), the laptop can securely respond to an authentication challenge with
1036 students -- this authentication can unlock extra services like backup and
its (SN, UUID) tuple. In addition to serving as a means for the school to
1037 access to a decentralized digital identity system such as OpenID.
exercise network access control -- we know about some schools, for instance,
1038
that do not wish to provide Internet access to alumni, but only current
1039 [[OpenID -> http://en.wikipedia.org/wiki/OpenID]] is particularly appealing
students -- this authentication can unlock extra services like backup and
1040 to OLPC, because it can be used to perpetuate passwordless access even on sites
access to a decentralized digital identity system such as OpenID.
1041 that normally require authentication, as long as they support OpenID. The most

1042 common mode of operation for current OpenID identity providers is to request
[[OpenID -> http://en.wikipedia.org/wiki/OpenID]] is particularly appealing
1043 password authentication from the user. With an OpenID provider service running
to OLPC, because it can be used to perpetuate passwordless access even on sites
1044 on the school server (or other trusted servers), logins to OpenID-enabled sites
that normally require authentication, as long as they support OpenID. The most
1045 will simply succeed transparently, because the child's machine has been
common mode of operation for current OpenID identity providers is to request
1046 authenticated in the background by P_SERVER_AUTH.
password authentication from the user. With an OpenID provider service running
1047
on the school server (or other trusted servers), logins to OpenID-enabled sites
1048
will simply succeed transparently, because the child's machine has been
1049
authenticated in the background by P_SERVER_AUTH.
== (A futuro) P_PASSWORD: Proteccion con clave
| display = block }}
1050 8.21. (For later implementation) P_PASSWORD: password protection

1051 ----------------------------------------------------------------
{{anchor|Chapter 8.21}}{{anchor|P_PASSWORD}}{{anchor|P_PASSWORD: password protection}}
1052
== (A futuro) P_PASSWORD: Proteccion con clave ==
1053 It is unclear whether this protection will make it in to generation 1 of the XO

1054 laptops. When implemented, however, it will allow the user to set a password to
Todavía no ha sido definido si esta protección entrará en la generación 1 de las laptops XO. Cuando sea instrumentada, sin embargo, le permitirá al usuario determinar un palabra clave (''password'') para ser usada con su identidad digital, iniciar la máquina y el acceso a algunos de sus archivos.
1055 be used for her digital identity, booting the machine, and accessing some of
{{ Translated text |
1056 her files.
It is unclear whether this protection will make it in to generation 1 of the XO
1057
laptops. When implemented, however, it will allow the user to set a password to
1058
be used for her digital identity, booting the machine, and accessing some of
1059
her files.
1060
| display = block }}

{{anchor|Chapter 9}}{{anchor|Addressing the threat model}}

= Considerando el modelo de riesgos =
= Considerando el modelo de riesgos =

1061 9. Addressing the threat model
Aquí examinamos las cinco categorías de "cosas malas" que el software puede hacer segun el [[#Chapter 7|Capítulo 7]], y explicamos como las protecciones enumeradas en el [[#Chapter 8|Capítulo 8]] ayudan. Las siguientes secciones son dadas en el mismo orden que en el modelo de riesgos del [[#Chapter 7|Capítulo 7]].
1062 ==============================
{{ Translated text |
1063
1064 We look at the five categories of "bad things" software can do as listed in
We look at the five categories of "bad things" software can do as listed in
1065 Chapter 7, and explain how protections listed in Chapter 8 help. The following
Chapter 7, and explain how protections listed in Chapter 8 help. The following
1066 sections are given in the same order as software threat model entries in
sections are given in the same order as software threat model entries in
1067 Chapter 7.
Chapter 7.
| display = block }}
1068

1069
{{anchor|Chapter 9.1}}{{anchor|Damaging the machine}}
1070
== Daniando la maquina ==
== Dañando la máquina ==

1071 9.1. Damaging the machine
P_BIOS_CORE se asegura que la BIOS solo pueda ser actualizada por imagenes BIOS provenientes de fuentes confiables. Un chico con una llave de desarrollador puede ''flashear'' cualquier BIOS deseada, aunque si somos capaces de instrumentar P_BIOS_COPY, la máquina permanecerá operacional aun si el chico ''flashea'' una BIOS rota o inservible. Los programas que buscan dañar al SO no lo pueden hacer a causa de P_SANDBOX y P_SF_RUN. Llegado el caso en el que usuario con P_SF_RUN deshabilitado fuese engañado para dañar su SO o lo hace accidentalmente, P_SF_CORE le permite restaurar al estado inicial (activación) al momento de re-iniciar o arrancar.
1072 -------------------------

1073
Los programas que intentan arruinar la NAND consumiendo los ciclos de escritura/borrado son controlados por medio de P_NAND_RL, y los ataques de agotamiento de disco en el espacio de borrador (''scratch'') son mantenidos bajo control por P_NAND_QUOTA. Los ataques de agotamiento del disco con documentos del usuario son mucho mas difíciles por P_DOCUMENT_RL.
1074 P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from

1075 trusted sources. A child with a developer key may flash whichever BIOS she
Los programas que sobrecargan la CPU son mantenidos en linea con P_CPU_RL. Y los de redes son controlados por medio de politicas P_NET.
1076 pleases, though if we are able to implement P_BIOS_COPY, the machine will
{{ Translated text |
1077 remain operational even if the child flashes a broken or garbage BIOS.
P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from
1078 Programs looking to damage the OS cannot do so because of P_SANDBOX and
trusted sources. A child with a developer key may flash whichever BIOS she
1079 P_SF_RUN. Should a user with P_SF_RUN disabled be tricked into damaging her OS
pleases, though if we are able to implement P_BIOS_COPY, the machine will
1080 or do so accidentally, P_SF_CORE enables her to restore her OS to its initial
remain operational even if the child flashes a broken or garbage BIOS.
1081 (activated) state at boot time.
Programs looking to damage the OS cannot do so because of P_SANDBOX and
1082
P_SF_RUN. Should a user with P_SF_RUN disabled be tricked into damaging her OS
1083 Programs trying to trash the NAND by exhausting write/erase cycles are
or do so accidentally, P_SF_CORE enables her to restore her OS to its initial
1084 controlled through P_NAND_RL, and disk exhaustion attacks in the scratch space
(activated) state at boot time.
1085 are curbed by P_NAND_QUOTA. Disk exhaustion attacks with user documents are

1086 made much more difficult by P_DOCUMENT_RL.
Programs trying to trash the NAND by exhausting write/erase cycles are
1087
controlled through P_NAND_RL, and disk exhaustion attacks in the scratch space
1088 CPU-hogging programs are reined in with P_CPU_RL. Network-hogging programs are
are curbed by P_NAND_QUOTA. Disk exhaustion attacks with user documents are
1089 controlled by policy via P_NET.
made much more difficult by P_DOCUMENT_RL.
1090

1091
CPU-hogging programs are reined in with P_CPU_RL. Network-hogging programs are
1092
controlled by policy via P_NET.
| display = block }}

{{anchor|Chapter 9.2}}{{anchor|Compromising privacy}}
== Vulnerando la privacidad ==
== Vulnerando la privacidad ==

1093 9.2. Compromising privacy
La lectura arbitraria y/o el envío de los documentos del usuario por la red es controlado por P_DOCUMENT, mientras que el marcar los documentos con el programa que los creó permite controlar el escenario en el cual un programa malicioso intenta hacer ''spam'' en el servicio de búsqueda. Los resultados de un único programa en las búsquedas puede ser ocultado (permanentemente), o eliminados del índice completamente.
1094 -------------------------

1095
P_DOCUMENT_RO protege al usuario en forma adicional al evitar una violación a la privacidad en gran escala por software que pretende ser un "visualizador" de un amplio grupo de documentos.
1096 Arbitrary reading and/or sending of the user's documents over the network is

1097 curbed by P_DOCUMENT, while tagging documents with the program that created
P_MIC_CAM hace que el espiar al usuario sea difícil, y P_X hace extremadamente difícil el robar palabras claves u otro tipo de información sensible, o monitorear el ingreso de texto desde otros programas en ejecución.
1098 them addresses the scenario in which a malicious program attempts to spam
{{ Translated text |
1099 the search service. Search results from a single program can simply be
Arbitrary reading and/or sending of the user's documents over the network is
1100 hidden (permanently), or removed from the index completely.
curbed by P_DOCUMENT, while tagging documents with the program that created
1101
them addresses the scenario in which a malicious program attempts to spam
1102 P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches
the search service. Search results from a single program can simply be
1103 by software that purports to be a "viewer" of some broad class of documents.
hidden (permanently), or removed from the index completely.
1104

1105 P_MIC_CAM makes eavesdropping on the user difficult, and P_X makes it very hard
P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches
1106 to steal passwords or other sensitive information, or monitor text entry from
by software that purports to be a "viewer" of some broad class of documents.
1107 other running programs.

1108
P_MIC_CAM makes eavesdropping on the user difficult, and P_X makes it very hard
1109
to steal passwords or other sensitive information, or monitor text entry from
1110
other running programs.
== Daniando los datos del usuario ==
| display = block }}
1111 9.3. Damaging the user's data

1112 -----------------------------
{{anchor|Chapter 9.3}}{{anchor|Damaging the user's data}}
1113
== Dañando los datos del usuario ==
1114 File store does not permit programs to overwrite objects such as e-mail and

1115 text which aren't opaque binary blobs. Instead, only a new version is stored,
El almacén de archivos (''file store'') no permite a los programas sobre-escribir objetos tales como e-mail y texto que no sean [http://es.wikipedia.org/wiki/BLOB blobs] binarios opacos. En vez de ello, una nueva versión es guardada, y el almacén de archivos (''file store'') presenta una lista completa con el histórico de versiones. Esto permite una amplia protección de los documentos contra borrado o corrupción a manos de programas maliciosos&mdash;que, por supuesto, tuvieron que obtener el permiso del usuario para mirar el archivo en cuestion para comenzar, como es explicado por P_DOCUMENT.
1116 and the file store exposes a list of the full version history. This affords a

1117 large class of documents protection against deletion or corruption at the hands
En el caso de los [http://es.wikipedia.org/wiki/BLOB blobs]&mdash;videos, música, imagenes&mdash;un programa malicioso con el cual el usuario específicamente abra un archivo dado posee la capacidad de corromperlo o borrarlo. Sin embargo, no podemos proteger al usuario de si mismo. Vale la pena destacar que el borrado esta limitado _únicamente_ a los archivos que el usuario ha abierto explícitamente. Más aún, P_DOCUMENT_BACKUP permite una salida aún en dicha situación, suponiendo que la máquina haya tenido la oportunidad de cruzarse con un servidor de respaldo (''backup'') (los servidores escolares de la OLPC se anuncian como tales).
1118 of a malicious program -- which, of course, had to obtain the user's
{{ Translated text |
1119 permission to look at the file in question in the first place, as explained in
File store does not permit programs to overwrite objects such as e-mail and
1120 P_DOCUMENT.
text which aren't opaque binary blobs. Instead, only a new version is stored,
1121
and the file store exposes a list of the full version history. This affords a
1122 For binary blobs -- videos, music, images -- a malicious program in which
large class of documents protection against deletion or corruption at the hands
1123 the user specifically opens a certain file does have the ability to corrupt or
of a malicious program -- which, of course, had to obtain the user's
1124 delete the file. However, we cannot protect the user from herself. We point
permission to look at the file in question in the first place, as explained in
1125 out that such deletion is constrained to _only_ those files which the user
P_DOCUMENT.
1126 explicitly opened. Furthermore, P_DOCUMENT_BACKUP allows a final way out even

1127 in such situations, assuming the machine came across a backup server (OLPC
For binary blobs -- videos, music, images -- a malicious program in which
1128 school servers advertise themselves as such).
the user specifically opens a certain file does have the ability to corrupt or
1129
delete the file. However, we cannot protect the user from herself. We point
1130
out that such deletion is constrained to _only_ those files which the user
1131
explicitly opened. Furthermore, P_DOCUMENT_BACKUP allows a final way out even
in such situations, assuming the machine came across a backup server (OLPC
school servers advertise themselves as such).
| display = block }}

{{anchor|Chapter 9.4}}{{anchor|Doing bad things to other people}}
== Haciendo cosas malas a otros ==
== Haciendo cosas malas a otros ==

1132 9.4. Doing bad things to other people
Las laptops XO serán poco apetecibles como relays de spam o clientes de [http://en.wikipedia.org/wiki/FloodNet floodnet] dado los límites impuestos a todos los programas carentes de firmas digitales por el P_NET. A pesar del atractivo que supone la escala de distribución de las XOs para ''spamming'' o ''flooding'', suponemos que la restricción de bajo uso de la red para software carentes de confianza&mdash;junto a la gran dificultad de escribir gusanos (''worms'') o software auto-propagante para las máquinas XO&mdash;reducirá drásticamente esta preocupación.
1133 -------------------------------------
{{ Translated text |
1134
1135 XO laptops will be quite unattractive as spam relays or floodnet clients due to
XO laptops will be quite unattractive as spam relays or floodnet clients due to
1136 network rate and transfer limits imposed on all non-signed programs by
network rate and transfer limits imposed on all non-signed programs by
1137 P_NET. Despite the appeal of the XO deployment scale for spamming or flooding,
P_NET. Despite the appeal of the XO deployment scale for spamming or flooding,
1138 we expect that a restriction to generally low-volume network usage for
we expect that a restriction to generally low-volume network usage for
1139 untrusted software -- coupled with the great difficulty in writing worms or
untrusted software -- coupled with the great difficulty in writing worms or
1140 self-propagating software for XO machines -- will drastically reduce this
self-propagating software for XO machines -- will drastically reduce this
1141 concern.
concern.
| display = block }}
1142

1143
{{anchor|Chapter 9.5}}{{anchor|Impersonating the user}}
1144
== Suplantando al usuario ==
== Suplantando al usuario ==

1145 9.5. Impersonating the user
El diseño del servicio de identidad, P_IDENT, no permite a los programas entrar jamás en contacto con el par de llaves o claves criptográficas del usuario, ni inyectar información en sesiones ya abiertas que esten usando el servicio de identidad para firmar o encriptarlas.
1146 ---------------------------
{{ Translated text |
1147
1148 The design of the identity service, P_IDENT, does not allow programs to
The design of the identity service, P_IDENT, does not allow programs to
1149 ever come in direct contact with the user's cryptographic key pair, nor to
ever come in direct contact with the user's cryptographic key pair, nor to
1150 inject information into currently-open sessions which are using the identity
inject information into currently-open sessions which are using the identity
1151 service for signing or encryption.
service for signing or encryption.
| display = block }}
1152

1153
{{anchor|Chapter 9.6}}{{anchor|Miscellaneous}}
1154
== Varios ==
== Varios ==

1155 9.6. Miscellaneous
Además de las protecciones ya mencionadas que contemplan distintas partes del modelo de riesgos, los permisos P_RTC y P_THEFT se combinan para ofrecer un sistema anti-robo que requiere de un grado de sofisticación importante (manipulación del hardware) para ser eliminado, y el P_DSP_BG provee una protección contra ciertos tipos de ''malware'' impertinentes, tales como el infame virus Yankee Doodle de 1989.
1156 ------------------
{{ Translated text |
1157
1158 In addition to the protections listed above which each address some part of the
In addition to the protections listed above which each address some part of the
1159 threat model, permissions P_RTC and P_THEFT combine to offer an anti-theft
threat model, permissions P_RTC and P_THEFT combine to offer an anti-theft
1160 system that requires non-trivial sophistication (ability to tamper with
system that requires non-trivial sophistication (ability to tamper with
1161 on-board hardware) to defeat, and P_DSP_BG provides protection against certain
on-board hardware) to defeat, and P_DSP_BG provides protection against certain
1162 types of annoying malware, such as the infamous 1989 Yankee Doodle virus.
types of annoying malware, such as the infamous 1989 Yankee Doodle virus.
| display = block }}
1163

1164
{{anchor|Chapter 9.7}}{{anchor|Missing from this list}}
1165
== Faltantes a esta lista ==
== Faltantes a la lista ==

1166 9.7. Missing from this list
Por lo menos dos problemas, comúnmente asociados con laptops y chicos como usuarios de computadoras respectivamente, no son discutidos en nuestro modelo de riesgo o sistemas de protección: la encriptación del disco rígido y el filtrado / control parental de contenido cuestionable.
1167 ---------------------------
{{ Translated text |
1168
1169 At least two problems, commonly associated with laptops and child computer
At least two problems, commonly associated with laptops and child computer
1170 users respectively, are not discussed by our threat model or protection
users respectively, are not discussed by our threat model or protection
1171 systems: hard drive encryption and objectionable content filtering / parental
systems: hard drive encryption and objectionable content filtering / parental
1172 controls.
controls.
| display = block }}
1173

1174
{{anchor|Chapter 9.7.1}}{{anchor|Filesystem encryption}}
=== Encriptacion del sistema de archivos ===
=== Encriptación del sistema de archivos ===
1175 === 9.7.1. Filesystem encryption ===

1176
Si bien las laptops XO no poseen un disco rígido técnicamente hablando, la pregunta sobre la encriptación de datos es perfectamente aplicable al almacenamiento primario de memoria flash. La respuesta consiste de dos partes: primero, la encriptación del sistema de archivos sería demasiado lenta para nuestro hardware. Las laptops XO pueden encriptar 2-4MiB/s usando el algoritmo [http://es.wikipedia.org/wiki/Advanced_Encryption_Standard AES-128] en modo CBC, usando 100% de la ''CPU''. Esto es aproximadamente 1/10 de la velocidad de transferencia del chip flash NAND. Cambiando a un algoritmo más rápido como el [http://es.wikipedia.org/wiki/RC4 RC4] permitiría aumentar la velocidad de encriptación a unos 15MiB/s usando bloques grandes y una utilización del 100% de la ''CPU'', y por lo tanto sigue siendo demasiado lento para un uso generalizado, y provee una seguridad cuestionable. En segundo lugar, dada la edad de nuestros usuarios, hemos diseñado la plataforma Bitfrost explícitamente para que no requiera del usuario el uso de palabras claves para controlar el acceso a su computadora. Pero sin palabras claves, la encriptación de datos del usuario tendría que recaer sobre identificadores únicos de la laptop misma, lo cual no brindaría ninguna protección a los datos en el caso de ser robada.
1177 While the XO laptops have no hard drive to speak of, the data encryption

1178 question applies just as well to our flash primary storage. The answer consists
Una vez que la plataforma Bitfrost soporte la protección P_PASSWORD, posiblemente no antes de la segunda generación de laptops XO, proveeremos el soporte para que el usuario encripte archivos individuales si es que la protección es activada y configurada con una palabra clave por el usuario.
1179 of two parts: firstly, filesystem encryption is too slow given our hardware.
{{ Translated text |
1180 The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC
While the XO laptops have no hard drive to speak of, the data encryption
1181 mode, using 100% of the available CPU power. This is about ten times less than
question applies just as well to our flash primary storage. The answer consists
1182 the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4
of two parts: firstly, filesystem encryption is too slow given our hardware.
1183 increases encryption throughput to about 15 MB/s with large blocks at 100% CPU
The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC
1184 utilization, and is hence still too slow for general use, and provides
mode, using 100% of the available CPU power. This is about ten times less than
1185 questionable security. Secondly, because of the age of our users, we have
the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4
1186 explicitly designed the Bitfrost platform not to rely on the user setting
increases encryption throughput to about 15 MB/s with large blocks at 100% CPU
1187 passwords to control access to her computer. But without passwords, user data
utilization, and is hence still too slow for general use, and provides
1188 encryption would have to be keyed based on unique identifiers of the laptop
questionable security. Secondly, because of the age of our users, we have
1189 itself, which lends no protection to the user's documents in case the laptop is
explicitly designed the Bitfrost platform not to rely on the user setting
1190 stolen.
passwords to control access to her computer. But without passwords, user data
1191
encryption would have to be keyed based on unique identifiers of the laptop
1192 Once the Bitfrost platform supports the P_PASSWORD protection, which might not
itself, which lends no protection to the user's documents in case the laptop is
1193 be until the second generation of the XO laptops, we will provide support for
stolen.
1194 the user to individually encrypt files if she enabled the protection and set a

1195 password for herself.
Once the Bitfrost platform supports the P_PASSWORD protection, which might not
1196
be until the second generation of the XO laptops, we will provide support for
1197
the user to individually encrypt files if she enabled the protection and set a
password for herself.
| display = block }}

{{anchor|Chapter 9.7.2}}{{anchor|Objectionable content filtering}}
=== Filtrado de contenido cuestionable ===
=== Filtrado de contenido cuestionable ===

1198 === 9.7.2. Objectionable content filtering ===
La plataforma Bitfrost es el gobernante del sistema de seguridad de las laptops XO. Dado que el término "contenido cuestionable" carece de toda definición técnica, siendo algo puramente social, el filtrado de dicho contenido cae fuera de los alcances de la plataforma de seguridad y este documento.
1199
{{ Translated text |
1200 The Bitfrost platform governs system security on the XO laptops. Given that
The Bitfrost platform governs system security on the XO laptops. Given that
1201 "objectionable content" lacks any kind of technical definition, and is instead
"objectionable content" lacks any kind of technical definition, and is instead
1202 a purely social construct, filtering such content lies wholly outside of the
a purely social construct, filtering such content lies wholly outside of the
1203 scope of the security platform and this document.
scope of the security platform and this document.
1204
| display = block }}
1205

1206
{{anchor|Chapter 10}}{{anchor|Laptop disposal and transfer security}}
1207
= Descarte de la laptop y seguridad de transferencia =
= Descarte de la laptop y seguridad de transferencia =

1208 10. Laptop disposal and transfer security
El tiempo de vida pensado para una laptop XO es de cinco años. Una vez transcurrido dicho tiempo, el propietario de la laptop puede querer deshacerse de ella. De modo similar, y por razones logísticas, una laptop puede cambiar de manos, de un dueño a otro.
1209 =========================================

1210
Un programa de re-inicialización de la laptop será provisto para borrar de manera segura la identidad digital del usuario y todos sus documentos de la laptop. De ser ejecutado en modo "descarte", el programa también podría deshabilitar permanentemente a la laptop, aunque no esta muy claro que dicha funcionalidad sea de hecho necesaria, y por lo tanto no hay planes para proveerla.
1211 The target lifetime of an XO laptop is five years. After this time elapses, the
{{ Translated text |
1212 laptop's owner might wish to dispose of the laptop. Similarly, for logistical
The target lifetime of an XO laptop is five years. After this time elapses, the
1213 reasons, a laptop may change hands, going from one owner to another.
laptop's owner might wish to dispose of the laptop. Similarly, for logistical
1214
reasons, a laptop may change hands, going from one owner to another.
1215 A laptop re-initialization program will be provided which securely erases the

1216 user's digital identity and all user documents from a laptop. When running in
1217 "disposal" mode, that program could also be made to permanently disable the
A laptop re-initialization program will be provided which securely erases the
user's digital identity and all user documents from a laptop. When running in
1218 laptop, but it is unclear whether such functionality is actually necessary, so
"disposal" mode, that program could also be made to permanently disable the
1219 there are no current plans for providing it.
laptop, but it is unclear whether such functionality is actually necessary, so
1220
there are no current plans for providing it.
1221
| display = block }}
1222

1223
{{anchor|Chapter 11}}{{anchor|Closing words}}
= Comentarios finales =
= Comentarios finales =

1224 11. Closing words
En la mitología Nórdica, Bifröst es el puente que impide a los mortales, habitantes de Midgard, aventurarse en Asgard, el dominio de los dioses. De hecho, Bifröst es un poderosos sistema de seguridad diseñdo para mantener alejados a intrusos no deseados.
1225 =================

1226
Esta no es la razón detrás del porque el nombre de la plataforma de seguridad de la OLPC es un juego sobre el mítico puente. Lo que es particularmente interesante de Bifröst es una historia que el historiador y poeta islandés [http://es.wikipedia.org/wiki/Snorri_Sturluson Snorri Sturlson] del siglo XII cuenta en su manual poético llamado [http://es.wikipedia.org/wiki/Edda_prosaica Edda prosaica]. He aquí un extracto relevante:
1227 In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of
{{ Translated text |
1228 the realm of Midgard, from venturing into Asgard, the realm of the gods. In
1229 effect, Bifröst is a powerful security system designed to keep out unwanted
In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of
the realm of Midgard, from venturing into Asgard, the realm of the gods. In
1230 intruders.
effect, Bifröst is a powerful security system designed to keep out unwanted
1231
intruders.
1232 This is not why the OLPC security platform's name is a play on the name of the

1233 mythical bridge, however. What's particularly interesting about Bifröst is a
This is not why the OLPC security platform's name is a play on the name of the
1234 story that 12th century Icelandic historian and poet Snorri Sturluson tells in
mythical bridge, however. What's particularly interesting about Bifröst is a
1235 the first part of his poetics manual called the Prose Edda. Here is the
story that 12th century Icelandic historian and poet Snorri Sturluson tells in
1236 relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:
the first part of his poetics manual called the Prose Edda. Here is the
1237
relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:
1238 Then said Gangleri: "What is the way to heaven from earth?"
| display = block }}
1239
<font size="1">
1240 Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has
::'''Nota: esta es una traducción ad-hoc al castellano de la traducción al inglés por [http://www.cybersamurai.net/Mythology/nordic_gods/LegendsSagas/Edda/ProseEdda/ContentsEnglish.htm Arthur Gilchrist Brodeur] de 1916.
1241 it not been told thee, that the gods made a bridge from earth, to heaven,
</font>
1242 called Bifröst? Thou must have seen it; it may be that ye call it rainbow.'
:Y entonces Gangleri dijo: "Cual es el camino al cielo desde a la tierra?"
1243 It is of three colors, and very strong, and made with cunning and with more
:Y entonces Hárr contestó, riéndose: "Vaya, no es preguntado de manera sabia; acaso no se le ha dicho, que los dioses han hecho un puente desde la tierra, al cielo, llamado Bifröst? Seguramente lo habrá visto; podría ser que lo conozca como arcoiris. Es de tres colores, y muy fuerte, hecho con ingenio y más artes mágicas que otros trabajos de manufactura. Pero fuerte como es, debe aún ser roto, cuando los hijos de Múspell avancen cargando y lo atraviesen, y naden con sus caballos sobre los grandes ríos; así será."
1244 magic art than other works of craftsmanship. But strong as it is, yet must
:Y entonces Gangleri dijo: "A mi parecer los dioses no construyeron el puente honestamente, sabiendo que puede ser roto, y siendo capaces de hacerlo como quisieran."
1245 it be broken, when the sons of Múspell shall go forth harrying and ride it,
:Y entonces Hárr respondió: "Los dioses no merecen ser recriminados por este trabajo habilidoso, un buen puente es Bifröst, pero nada en este mundo es de naturaleza tal de ser confiado cuando los hijos de Múspell cargan.&quot;
1246 and swim their horses over great rivers; thus they shall proceed."
{{ Translated text |
1247
1248 Then said Gangleri: "To my thinking the gods did not build the bridge
Then said Gangleri: "What is the way to heaven from earth?"

1249 honestly, seeing that it could be broken, and they able to make it as they
Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has
1250 would."
it not been told thee, that the gods made a bridge from earth, to heaven,
1251
called Bifröst? Thou must have seen it; it may be that ye call it rainbow.'
1252 Then Hárr replied: "The gods are not deserving of reproof because of this
It is of three colors, and very strong, and made with cunning and with more
1253 work of skill: a good bridge is Bifröst, but nothing in this world is of
magic art than other works of craftsmanship. But strong as it is, yet must
1254 such nature that it may be relied on when the sons of Múspell go
it be broken, when the sons of Múspell shall go forth harrying and ride it,
1255 a-harrying."
and swim their horses over great rivers; thus they shall proceed."
1256

1257 This story is quite remarkable, as it amounts to a 13th century recognition of
Then said Gangleri: "To my thinking the gods did not build the bridge
1258 the idea that there's no such thing as a perfect security system.
honestly, seeing that it could be broken, and they able to make it as they
1259
would."
1260 To borrow Sturluson's terms, we believe we've imbued the OLPC security system

1261 with cunning and more magic art than other similar works of craftmanship -- but
Then Hárr replied: "The gods are not deserving of reproof because of this
1262 not for a second do we believe we've designed something that cannot be broken
work of skill: a good bridge is Bifröst, but nothing in this world is of
1263 when talented, determined and resourceful attackers go forth harrying. Indeed,
such nature that it may be relied on when the sons of Múspell go
1264 this was not the goal. The goal was to significantly raise the bar from the
a-harrying."
1265 current, deeply unsatisfactory, state of desktop security. We believe Bitfrost
| display = block }}
1266 accomplishes this, though only once the laptops are deployed in the field will

1267 we be able to tell with some degree of certainty whether we have succeeded.
Esta historia es notable, ya que en suma es el reconocimiento que desde el siglo XIII existe la idea de que no existe un sistema de seguridad perfecto.
1268

1269 If the subject matter interests you, please join the OLPC security mailing
Usando los terminos de Sturluson, creemos haber imbuído al sistema de seguridad de la OLPC con ingenio y más artes mágicas que otros trabajos de manufactura&mdash;pero ni por un segundo creemos que hemos diseñado algo que no pueda ser roto cuando talentosos, determinados e ingeniosos atacantes carguen. De hecho, esa no era la meta. La meta era elevar significativamente la barrera del actual y profundamente insatisfactorio estado de la seguridad del escritorio (''desktop''). Creemos que Bitfrost cumple con ello, aunque solamente cuando las laptops esten en el campo seremos capaces de determinar con algún grado de certitud si lo hemos logrado.
1270 list, share your thoughts, and join the discussion.

1271
Si el tema les interesa, por favor unanse a la lista de seguridad de la OLPC, comparta sus ideas, y unase al debate.
1272

1273
FIN
1274
{{ Translated text |
1275
This story is quite remarkable, as it amounts to a 13th century recognition of
1276 END
the idea that there's no such thing as a perfect security system.

To borrow Sturluson's terms, we believe we've imbued the OLPC security system
with cunning and more magic art than other similar works of craftmanship -- but
not for a second do we believe we've designed something that cannot be broken
when talented, determined and resourceful attackers go forth harrying. Indeed,
this was not the goal. The goal was to significantly raise the bar from the
current, deeply unsatisfactory, state of desktop security. We believe Bitfrost
accomplishes this, though only once the laptops are deployed in the field will
we be able to tell with some degree of certainty whether we have succeeded.

If the subject matter interests you, please join the OLPC security mailing
list, share your thoughts, and join the discussion.


END
| display = block }}

= Créditos =

== Autor ==

:Ivan Krstić
:ivan EN laptop.org
:One Laptop Per Child
:http://laptop.org
{{ Translated text |
5 :Author
6 Ivan Krstić
7 ivan AT laptop.org
8 One Laptop Per Child
9 http://laptop.org
| display = none }}

== Agradecimientos ==

Simson Garfinkel, un consultor de seguridad para la OLPC, contribuyó a este documento. Este documento también se basa sobre un área en crecimiento conocido como "HCI-SEC", el campo de recientes avances de la Interacción Humano Computadora con el importante objetivo de la seguridad informática. Para más informacion sobre ''HCI-SEC'' referirse a "Security and Usability", por Lorrie Cranor y Simson Garfinkel (O'Reilly, 2005), y en la tésis PhD de Garfinkel, "Design Principles and Patterns for Computer Systems that are Simultaneously Secure and Usable" (MIT, 2005).
:Reconocemos también al panel de ''reviewers'' que prefieren permanecer anónimos, y que proveyeron comentarios y observaciones valiosos sobre las versiones previas de este documento.
{{ Translated text |
11 :Acknowledgments
12 Simson Garfinkel, a security consultant for OLPC, contributed to this
13 document. This document also builds upon a growing body known as
14 "HCI-SEC," the application of recent advances in the field of Human
15 Computer Interaction to the important goals of computer security. More
16 information about HCI-SEC can be found in the book "Security and
17 Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in
18 Garfinkel's PhD thesis, "Design Principles and Patterns for Computer
19 Systems that are Simultaneously Secure and Usable" (MIT, 2005).
20
21 We acknowledge also a panel of reviewers that prefer to stay anonymous, who
22 provided insightful comments and feedback on previous drafts of this
23 document.
| display = none }}

== Metadata ==
:Revisión: Borrador-19 - distribución 1
:Fecha y hora: Wed Feb 7 00:50:57 UTC 2007
:URL comentarios: http://mailman.laptop.org/mailman/listinfo/security
:Versión de referencia para este documento: http://wiki.laptop.org/go/Bitfrost
:Todo comentario sobre este documento será bienvenido, preferentemente en la lista pública de la OLPC sobre seguridad, a la cual se pueden suscribir por medio del URL ya mencionado. Si prefiere mantener sus comentarios privados, puede enviar un email al autor de este documento a su dirección arriba mencionada.
:Esta versión de la especificación NO es la definitiva. Sus contenidos reflejan exactamente el pensamiento de la OLPC en materia de seguridad al momento de ser redactado, pero ciertos aspectos del modelo de seguridad pueden cambiar antes de la producción. Este documento será actualizado para reflejar dichos cambios. La versión más reciente se puede encontrar en el URL de referencia.
{{ Translated text |
25 :Metadata
26 Revision: Draft-19 - release 1
27 Timestamp: Wed Feb 7 00:50:57 UTC 2007
28 Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
29 Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost
30
31 We welcome feedback on this document, preferably to the public OLPC
32 security mailing list, for which you can sign up at the feedback URL given
33 above. If you strongly prefer to keep your comments private, you may mail
34 the author of the document at the provided e-mail address.
35
36 This is NOT the final version of the specification. The contents of this
37 document accurately reflect OLPC's thinking about security at the time of
38 writing, but certain aspects of the security model may change before
39 production. This document will be updated to reflect any such changes. The
40 latest version of this document may be found at the authoritative version
41 URL.
| display = none }}

[[Category:Security]]

Latest revision as of 07:54, 17 December 2008

  Esta página está supervisada por el equipo de OLPC.
  Traducción de OLPC Bitfrost original  
  english | español日本語   +/- cambios  
This is an on-going translation

Seguridad de la laptop XO de la OLPC

Plataforma de seguridad Bitfrost

System security on the One Laptop per Child's XO laptop

The Bitfrost security platform

Introducción

Prefacio

En 1971, los programadores Ken Thompson y Dennis Ritchie de AT&T produjeron la primera versión de UNIX. El sistema operativo, que comenzó en 1969 como un proyecto no-pago llamado UNICS, fue renombrado y financiado por Bell Labs cuando los programadores ofrecieron agregarle soporte para el procesamiento de texto. Muchas de esas ideas centrales detrás de Unix aún persisten hoy en día: los populares sistemas operativos para servidores como Linux, FreeBSD, y muchos otros comparten mucho del diseño básico de UNIX.

La versión de UNIX de 1971 soportaba los siguientes permisos de seguridad en los archivos de usuarios:

  • no-dueño puede cambiar el archivo (escritura)
  • no-dueño puede leer el archivo
  • dueño puede cambiar el archivo (escritura)
  • dueño puede leer el archivo
  • el archivo puede ser ejecutado
  • el archivo es set-uid

In 1971, 35 years ago, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.

The 1971 version of UNIX supported the following security permissions on user files:

  • non-owner can change file (write)
  • non-owner can read file
  • owner can change file (write)
  • owner can read file
  • file can be executed
  • file is set-uid

Estos permisos deben parecerles familiares, ya que son muy similares a los permisos de seguridad que un usuario puede darle a sus archivos hoy en día, en su sistema operativo de elección. Lo que es preocupante—casi increíble—acerca de estos permisos es que han permanecido virtualmente como el único mecanismo de control real que un usuario tiene sobre sus documentos personales actualmente: un usuario puede elegir proteger sus archivos de otras personas en el sistema, pero no tiene ningún control sobre lo que sus programas pueden hacer sobre sus archivos.

En 1971, esto podía ser aceptable: fue 20 años antes del arribo de la Web, y los riesgos para la mayoria de los usuarios era totalmente diferente al que se aplica hoy en día. Pero entonces, como es que nos sorprendemos al no poder detener los virus y malware, cuando nuestras defensas han permanecido básicamente las mismas desde hace 35 años?

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling -- almost unbelievable -- about these permissions is that they've remained virtually the _only_ real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

El corazón del problema radica en el supuesto que cualquier programa ejecutándose en el sistema a cuenta de un usuario debería tener las mismas habilidades y permisos que cualquier otro programa ejecutándose en el sistema a cuenta del mismo usuario. 1971 fue siete años antes que la primera red internacional (basada en packet-switch) existiese. Y la primera red de área amplia (wan - wide area network) usando TCP/IP, el estándar de la actual Internet, no fue creada sino hasta 1983, doce años después que Thompson y Ritchie diseñaran los permisos de archivos que ahora discutimos. En resumidas cuentas, en 1971 casi no existía la posibilidad que un programa "existiera" en una computadora excepto si el dueño de la cuenta—el usuario—lo transportaba físicamente a una máquina (por ejemplo, en cinta perforada), o lo ingresase manualmente. Y por ende, la aproximación a la seguridad del "todo o nada", donde los programas ejecutándose tienen el control total sobre la cuenta de su dueño, tenían sentido: cualquier código que el usuario ejecutáse, gozaba de su confianza ipso-facto en términos prácticos.

The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner -- the user -- physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.

Avancemos en el tiempo a la actualidad, y la situación no podría ser más diferente: el contraste máximo es quizás la Web, donde el navegador (browser) ejecuta código foráneo en prácticamente todas la páginas visitadas! Los navegadores utilizan mecanismos de areneros (sandbox) cada vez más complejos con la intención de restringir las capacidades para dicho código foráneo (scripts), pero aún los navegadores más modernos están corrigiendo errores en ellos. Y no nos olvidemos del e-mail: cualquiera puede enviarle a un usuario un programa ejecutable, y por muchos años, la reacción casi instintiva era abrirlo y ejecutarlo. El código foráneo no digno de confianza a priori se encuentra por todos lados, y la única defensa pareciera ser un tedioso entrenamiento del usuario y el software anti-virus—suponiendo que este último esté actualizado, y que sus fabricantes hayan tenido el tiempo suficiente para desconstruir cada virus nuevo y construir su correspondiente defensa.

Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and antivirus software -- the latter assuming it's fully updated, and assuming the antivirus makers have had time to deconstruct each latest virus and construct a defense for it.

La mayoría de las ideas y tecnologías que conforman la plataforma Bitfrost no son el resultado de nuevas investigaciones: han sido conocidas en la literatura pertinente durante años, algunas han sido probadas en situaciones reales, y otras en laboratorios. Lo que se destaca en la XO de la OLPC, es que representa la primera vez que estas medidas de seguridad han sido cuidadosamente ensambladas en un sistema a ser distribuido a decenas o centenas de millones de usuarios. Las laptops son probablemente la primvera vez que un producto de computación masiva ha decidido romper con su legado con tal de mejorar la seguridad. Por ejemplo, notarán que la discusión sobre anti-virus y anti-spyware no figura en la especificación de Bitfrost, principalmente porque la plataforma de seguridad torna dicho tema en algo irrelevante.

Most technologies and approaches mentioned in the rest of this document do not represent original research: they have been known in the security literature for years, some of them have been deployed in the field, and others are being tested in the lab. What makes the OLPC XO laptops radically different is that they represent the first time that all these security measures have been carefully put together on a system slated to be introduced to tens or hundreds of millions of users. The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security. As an example, you'll find that talk about anti-virus and anti-spyware technology is conspicuously absent from this document, because the Bitfrost security platform on the XO laptops largely renders these issues moot.

Nos hemos puesto como objetivo crear un sistema que sea drásticamente más seguro y usable que cualquier otro sistema masivo actualmente en el mercado. Un resultado de la dedicación a la usabilidad es que sólo existe una protección provista por Bitfrost que requiere una respuesta del usuario, y aún entonces, es una sencilla pregunta por 'si o no' comprehensible aún por un chico pequeño. El resto de la seguridad es provista tras bambalinas. El llevar al límite los aspectos de usabilidad y seguridad no es fácil, y es importante destacar que no hemos intentado crear, y no creemos que lo hayamos hecho, un sistema "perfectamente seguro". La idea de seguridad perfecta en el mundo real es vana, y negamos todo tipo de insinuacion que lo hayamos logrado.

We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and as we state in the concluding chapter of this document, we have neither tried to create, nor do we believe we have created, a "perfectly secure" system. Notions of perfect security are foolish, and we distance ourselves up front from any such claims.

La Seguridad y la OLPC

En términos de seguridad, la laptop XO de la OLPC es un ambiente muy particular. Su intención es introducir a chicos pequeños a la computación, muchos en ambientes que no han sido expuestos previamente a la computación o la Internet.

Aún más, la OLPC no tiene como objetivo una distribución reducida donde podría intervenir rápidamente de existir algún problema de seguridad con las máquinas o su uso; en vez, una vez distribuídas, cambios importantes en el modelo de seguridad podrían ser considerados difíciles o imposibles.

In terms of security, the OLPC XO laptops are a highly unique environment. They are slated to introduce computers to young children, many in environments that have had no prior exposure to computing or the Internet.

What's more, OLPC is not targeting small-scale local deployments where it could easily intervene in the case of security problems with the machines or their usage; instead, once the machines are released in the wild, drastic changes in the security model should be considered difficult or impossible.

Existe suficiente experiencia en bloquear las máquinas de los usuarios, usualmente en ambientes empresariales o académicos. Pero la OLPC tienen un requisito que invalida la mayor parte del conocimiento común: la OLPC es, por diseño, luchando para ser una plataforma inherentemente maleable, permitiendo a los chicos modificar, adaptar, o "hackear", sus propias máquinas como a ellos les plazca.

El resultado es que ninguna política de seguridad sobre la computadora puede satisfacer nuestros requerimientos. En su lugar, distribuiremos y activaremos una politica rigurosa de seguridad apropiada aún al más jóven de los usuarios, y que sea capaz de proveer la máxima seguridad disponible. Sin embargo, proveeremos una interfaz gráfica simple con tal que los usuarios interesados puedan deshabilitar cualquiera de las protecciones, permitiendo al usuario ajustar el nivel de seguridad acorde a su interes en hackear su máquina.

Plenty of experience exists in locking down user machines, often in corporate or academic settings. But OLPC has a final constraint that invalidates most of the current common wisdom: OLPC is, by design, striving to be an eminently malleable platform, allowing the children to modify, customize, or "hack", their own machines any way they see fit.

As a result, no one security policy on the computer will satisfy our requirements. Instead, we will ship and enable by default a stringent policy that's appropriate even for the youngest user, and which delivers the strongest available protections. However, we will provide a simple graphical interface for interested users to disable any of these protections, allowing the user to tailor the security level to match her interest in hacking her machine.

Este modo nos permite ser extremadamente seguros por defecto, y proteger aún al usuario que no tiene ningún concepto de la seguridad digital. Al mismo tiempo, evita el interponerse en el camino del usuario cada vez más sofisticado, e interesado en aumentar sus habilidades con la máquina.

Finalmente, y dado que suscribimos a las teorías de aprendizaje constructivistas, eventualmente queremos incitar a todos los chicos a progresar a un nivel de sofisticación mayor y así tomar mayores libertades con su máquina. Sin embargo, mientras exista el potencial de desastre (ej: tornar la máquina totalmente inoperable, o pérdida total de datos), dicho potencial es un gran obstáculo para el progreso. Y es por eso que además de focalizarse en la seguridad, nos enfocamos explícitamente en proveer mecanismos que logren la recuperación de un modo trivial y no intimidante, como podría ser la recuperación del sistema operativo de múltiples fuentes y copias de respaldo desde un servidor central.

This approach allows us to be highly secure by default, and protect even the user who has no conception of digital security. At the same time, it avoids getting in the way of any user who is becoming more sophisticated, and interested in increasing her abilities on the machine.

Finally, because we subscribe to constructionist learning theories, we want to encourage children to all eventually progress to this level of a more sophisticated user who takes greater liberties with her machine. However, as long as there exists potential for disaster (i.e. rendering a machine fully inoperable, or incurring total data loss), this potential serves as a strong deterrent to this progression. Because of this, in addition to focusing on security by default, we are explicitly focusing on providing mechanisms for trivial and unintimidating disaster recovery, such as operating system recovery from multiple sources and data backup to a central server.

Acerca de este documento

Este documento hace un seguimiento de la seguridad a lo largo del ciclo de vida de la laptop en si, comenzando cuando la laptop es producida en la fábrica, al momento en que llega la chico por primera vez, a lo largo del uso de la laptop por el chico, y finalmente el momento en que el chico se deshace o descarta la laptop. Todo esto es precedido por una breve sección sobre nuestras metas y principios, que sirven como fondo para algunas decisiones que han sido tomadas, y quizás no sean obvias si uno piensa sobre la seguridad en el contexto de una laptop o computadora de escritorio normal.

Este documento es completo en cuanto lo que se refiere al modelo de seguridad de la OLPC, pero es generalmente no-técnico. Un documento anexo se encuentra en preparación para complementar este con comentarios y descripciones técnicas completas.

This document follows security throughout the life-cycle of the laptop itself, starting from the moment a laptop is produced in the factory, to the moment it first reaches a child, throughout the child's use of the laptop, and finally stopping at the moment a child wishes to dispose of the laptop. All of this is preceded by a short section on our goals and principles, which serves to provide background to some of the decisions we made, and which might be non-obvious if one thinks of security in the context of normal laptop and desktop machines.

This document is complete with regard to the OLPC security model, but is generally non-technical. A separate document is being prepared that complements this one with fully technical descriptions and commentary.

Principios y objetivos

Principios

Diseño abierto
La seguridad de la laptop no puede depender de algun diseño secreto implantado en el hardware o software.
Sin bloqueos
A pesar que varios parametros por defecto, el sistema de seguridad de la laptop puede imponer varias prohibiciones a las acciones del usuario, debe existir la manera por la cual éstos sistemas de seguridad puedan ser deshabilitados. En dicho caso, la máquina le permitirá al usuario un control absoluto.
Sin lecturas requeridas
La seguridad no puede depender de la habilidad del usuario de leer un mensaje de la computadora y actuar de manera informada y razonable. Si bien el deshabilitar un mecanísmo particular puede requerir una lectura, la máquina debe ser segura desde la fábrica si es entregada a algún usuario que todavía no sabe leer.
Seguridad que no obstruya
Siempre que sea posible, la seguridad en las máquinas debe realizarse tras bambalinas, haciendose notar sólamente por medio de sutiles indicadores visuales o audio, y nunca interponiéndose en el camino del usuario. De existir un conflicto leve frente a la comodidad del usuario, la seguridad máxima toma precedencia, aunque cuidados extremos deben llevarse a cabo con el fin de asegurarse que dichos permisos no reduzcan seriamente o solapadamente la usabilidad de las máquinas.
Por ejemplo, si un programa es descubierto en el intento de violar una medida de seguridad, no se le preguntará al usuario para permitir dicha acción; que será simplemente negada. Si el usuario desea otorgar dicho permiso, ello puede ser hecho en la interfaz gráfica del centro de seguridad.
Open design
The laptop's security must not depend upon a secret design implemented in hardware or software.
No lockdown
Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control.
No reading required
Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism _may_ require reading, a machine must be secure out of the factory if given to a user who cannot yet read.
Unobtrusive security
Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines.
As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.

Objetivos

Sin claves de usuario
Con usuarios jóvenes (a partir de los cinco años), la seguridad de la laptop no puede depender del habilidad del usuario de recordar una clave. No se puede suponer que los usuarios elijan una clave cuando las reciban por primera vez.
Sin autentificación no-encriptada
La autentificación de las laptops o sus usuarios no dependerá de identificadores transmitidos sin encriptar en la red. Esto quiere decir que claves visibles de ningún tipo pueden ser usadas en los protocolos OLPC y que el MAC de Ethernet jamás serán usados como autentificación.
Seguridad desde la caja
La laptop deberá ser usable y segura desde la caja, sin necesidad de realizar o descargar actualizaciones de seguridad en la medidad de lo posible.
Uso limitado de PKI institucional
La laptop estará provista con llaves públicas de la OLPC y la autoridad del el país o región (ej: ministerio o departamento de educación), pero estas llaves no serán usadas para validar la identidad de los usuarios. El único propósito de estas llaves es verificar la integridad del software y contenido incluído en la laptop. Los usuarios serán identificados por medio de un sistema orgánico PKI sin una cadena de confianza certificada (without a certified chain of trust)—en otras palabras, nuestro enfoque a PKI es KCM (Key-Continuity Management).
Sin pérdida permanente de datos
La información en la laptop será replicada sobre algún almacenamiento centralizado de modo tal que el estudiante pueda recuperarla en el caso que la laptop se pierda, sea robada o destruida.
No user passwords
With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers.
No unencrypted authentication
Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication.
Out-of-the-box security
The laptop should be both usable and secure out-of-the-box, without the need to download security updates when at all possible.
Limited institutional PKI
The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust -- in other words, our approach to PKI is KCM, or key continuity management.
No permanent data loss
Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the even that the laptop is lost, stolen or destroyed.

Producción en planta

Como parte de su proceso de producción en la planta, ciertos datos relativos a su manufactura son grabados en un chip flash SPI embarcado. El chip es re-escribible, pero obviando la manipulación del hardware, solamente por un proceso de confianza que no dañará o modificará dicha información.

Los datos de manufactura incluyen dos identificadores únicos: NS, el número de serie (o SN - serial number) y U#, un UUID (universally unique identifier) generado al azar. Los números de serie no son asignados secuencialmente; sino que son elegidos al azar a partir de un conjunto de enteros. El proceso de manufactura mantiene la correspondencia entre numero de serie asignado al azar con el número de serie real secuencial que comenzó en 1 con la primera laptop producida. Esta correspondencia es confidencial pero no secreta, y es mantenida por la OLPC.

As part of factory production, certain manufacturing data is written to the built-in SPI flash chip. The chip is rewritable, but barring hardware tampering, only by a trusted process that will not damage or modify the manufacturing information.

Manufacturing data includes two unique identifiers: SN, the serial number, and U#, the randomly-generated UUID. Serial numbers are not assigned in order; instead, they are chosen randomly from a pool of integers. The manufacturing process maintains a mapping of the random serial number assigned, to the real, incremental serial number which was set to 1 for the first laptop produced. This mapping is confidential but not secret, and is kept by OLPC.

El único objetivo de esta correspondencia al azar es para desalentar cualquier intento de usar los números de series de las laptops entregadas en diferentes países para intentar analizar los volúmenes de compra de cada país.

El UUID de cada laptop, U#, es una secuencia al azar de 32 bytes ASCII imprimibles.

En una de las etapas de diagnósticos en la planta tras haber sido producida, la herramienta de diagnóstico enviará toda la información relacionada a su manufactura, incluyendo el U#, NS y la información de la planta a un servidor de la OLPC. Esta información será encolada en la planta ante cualquier problema de conectividad, y por lo tanto no se perderá bajo ninguna situación prevista.

Al salir de la linea de producción, la laptop se encuentra en modo "desactivada". Esto quiere decir que deberá pasar por el proceso de activación criptográfica cuando sea encendida, antes de poder ser usada por el usuario final.

The random mapping's sole purpose is to discourage attempts at using serial numbers of laptops delivered to different countries for attempting to analyze countries' purchase volumes.

A laptop's UUID, U#, is a random 32-byte printable ASCII identifier.

In one of the factory diagnostics stages after each laptop's production, the diagnostics tool will send the complete manufacturing information, including U#, SN, and factory information, to an OLPC server. This information will be queued at the factory in case of connectivity issues, and so won't be lost under any foreseeable circumstances.

At the end of the production line, the laptop is in the 'deactivated' state. This means it must undergo a cryptographic activation process when powered on, before it can be used by an end user.

Seguridad en la cadena de distribución

La OLPC solo se encarga del embarque de las laptops de su planta de origen al país comprador. El despacho y distribución dentro de cada país es totalmente organizado y responsabilidad de cada país.

Dados los volúmenes de producción de la OLPC, la cadena de distribución supone un vector de ataque atractivo para un ladrón emprendedor. El requerimiento para la activación torna el robo en la etapa de entrega inapetecible, requiriendo una intervención a nivel de hardware sobre cada laptop robada antes de su reventa. Damos una revista al proceso de activación más abajo.

OLPC arranges only the shipment of laptops from their origin factory to each purchasing country. Shipping and delivery within each country is organized fully by the country.

Given OLPC production volumes, the delivery chain poses an attractive attack vector for an enterprising thief. The activation requirement makes delivery theft highly unappealing, requiring hardware intervention to disable on each stolen laptop before resale. We give an overview of the activation process below.

Arribo a la escuela y activacion

Antes que una partida sea despachada a cada escuela, el país utiliza un software provisto por la OLPC para generar una partida de códigos de activación. Esta "lista de activación" posee la tupla (NS, UUID) y su correspondiente código de activación único para cada laptop referenciada. Las listas de activación son generadas por el mismo pais, a medida que las laptops son organizadas en partidas para ser entregadas a escuelas específicas. En otras palabras, no existe una lista maestra de activación.

La lista de activación para cada partida de laptops es cargada a un disco USB, y entregada al responsable de las entregas del proyecto en la escuela destinataria fuera del circuito de entrega efectivo de las laptops. Este responsable de las entregas será comunmente un maestro u otro funcionario administrativo de la escuela. La lista de activación enviada a una escuela no puede ser usada para activar ninguna otra partida.

Before a batch of laptops is shipped to each school, the country uses OLPC-provided software to generate a batch of activation codes. This "activation list" maps each (SN, UUID) tuple to a unique activation code for the referenced laptop. Activation lists are generated on-demand by the country for each laptop batch, as the laptops are partitioned into batches destined for specific schools. In other words, there is no master activation list.

The activation list for a laptop batch is loaded onto a USB drive, and delivered to a project handler in the target school out of band from the actual laptop shipment. The handler will be commonly a teacher or other school administrator. The activation list sent to one school cannot be used to activate any other laptop batch.

Cuando el la lista de activación en el disco USB es recibida, este será conectado al servidor provisto por la OLPC, u otro servidor que pueda ejecutar el software requerido y que se encuentre conectado a un punto de acceso inalámbrico. Cualquier servidor que tome este rol será referido como el 'servidor de activación'. Una laptop XO activada podría ser usada para este propósito de ser necesario.

Tras la recepción de la partida de laptops correspondiente, el responsable de distribución de la escuela tendrá la tarea de entregar a cada chico su laptop. Cuando un chico reciba una laptop, esta estará aún desactivada. Será el chico quien deberá encender la laptop dentro del alcance del punto de acceso inalámbrico del servidor de activación. Cuando esto ocurra, la laptop comunicará de forma segura su tupla (NS, UUID) al servidor, el cual retornará el código de activación en cuestión, suponiendo que la tupla se encuentra en la lista de activación, o un error de no ser así.

When the activation list USB drive is received, it is plugged into the OLPC-provided school server, or another server running the requisite software that is connected to a wireless access point. Whichever server takes on this role will be called the 'activation server'. An activated XO laptop can be used for this purpose, if necessary.

After receiving the matching laptop batch, the school's project handler will be tasked with giving a laptop to each child at the school. When a child receives a laptop, it is still disabled. The child must power on the laptop within wireless range of the school's activation server. When this happens, the laptop will securely communicate its (SN, UUID) tuple to the server, which will return the activation code for the laptop in question, provided the tuple is found in the activation list, or an error if it isn't.

Dado un código de activación inválido o un error, la laptop dormirá durante una hora antes de volver a intentar su activación. Si el código de activación es válido, la laptop esta 'activada', y procede a la primera pantalla de encendido. Un código de activación textual puede ser ingresado manualmente en la máquina, si no se activara automáticamente por alguna razón.

Given an invalid activation code or an error, the laptop will sleep for one hour before retrying activation. If the activation code is valid, the laptop becomes 'activated', and proceeds to boot to the first-boot screen. A textual activation code can be entered into the machine manually, if the machine is not activating automatically for any reason.

Primer encendido

La primera vez que se enciende, un programa se ejecuta preguntandole al chico su nombre, toma una foto, y genera el par de claves ECC en el interin. El par de claves no se encuentra inicialmente protegido por una frase de paso (passphrase) y es asi usada para firmar tanto el nombre como la foto del chico. Esta informacion y la firma son la 'identidad digital' del chico.

La laptop transmite la tupla (NS, UUID, identidad digital) al servidor de activación. La correspondencia entre la laptop y la identidad del usuario es mantenida por las autoridades regionales o nacionales con fines anti-robo, pero nunca llega a la OLPC.

Después de esto, la laptop se inicia normalmente, con toda la seguridad activada.

On first boot, a program is run that asks the child for their name, takes their picture, and in the background generates an ECC key pair. The key pair is initially not protected by a passphrase, and is then used to sign the child's name and picture. This information and the signature are the child's 'digital identity'.

The laptop transmits the (SN, UUID, digital identity) tuple to the activation server. The mapping between a laptop and the user's identity is maintained by the country or regional authority for anti-theft purposes, but never reaches OLPC.

After this, the laptop boots normally, with all security settings enabled.

Instalación de software

Hay una distinción importante entre dos amplios tipos de programas que se ejecutan en un sistema, y esta distinción no usualmente es mencionada en la literatura sobre seguridad. Existen programas que son intencionalmente maliciosos, implicando que son escritos con dichos fines desde un principio, como los virus y worms, y otros programas que son circunstancialmente maliciosos pero que de otro modo son benignos, tales como programas legítimos que han sido vulnerados por un atacante mientras se ejecutan, y son utilizados para ejecutar código para el atacante por medio de la inyección de código u otro mecanismo.

Esta diferenciación es crucial y no puede ser subestimada, pues es un supuesto razonable que la mayor parte del software ejecutandose en una máquina normal comienza como benigno. De hecho, hemos observado que es por medio de la usurpación del software benigno que la mayor parte del software maligno es _introducido_ por primera vez en muchas máquinas, por lo tanto, el proteger al software benigno se convierte en algo doblemente importante.

There is a very important distinction between two broad classes of programs that execute on a running system, and this distinction is not often mentioned in security literature. There are programs that are purposely malicious, which is to say that they were written with ill intent from the start, such as with viruses and worms, and there are programs which are circumstantially malicious but otherwise benign, such as legitimate programs that have been exploited by an attacker while they're running, and are now being instrumented to execute code on behalf of the attacker via code injection or some other method.

This difference is crucial and cannot be understated, because it's a reasonable assumption that most software running on a normal machine starts benign. In fact, we observe that it is through exploitation of benign software that most malicious software is first _introduced_ to many machines, so protecting benign software becomes a doubly worthy goal.

La protección del software benigno es una piedra fundamental en nuestro modelo de seguridad. Y lo utilizamos con la siguiente idea en mente: el software benigno no mentirá sobre sus propósitos durante su instalación.

Como ejemplo, tomemos el juego de Solitario distribuído con muchas versiones de Microsoft Windows. Dicho programa no necesita:

  • ningún tipo de acceso a la red
  • ninguna capacidad de lectura de los documentos del usuario
  • ninguna capacidad para utilizar la cámara o micrófono embarcados
  • ninguna capacidad para mirar, o modificar, otros programas

The protection of benign software is a keystone of our security model. We approach it with the following idea in mind: benign software will not lie about its purpose during installation.

To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:

  • no network access whatsoever
  • no ability to read the user's documents
  • no ability to utilize the built-in camera or microphone
  • no ability to look at, or modify, other programs

Y si de algún modo es vulnerado por un atacante, el Solitario es libre de hacer cualquier cosa que desee el atacante, incluyendo:

  • leer, corromper o borrar documentos del usuario, planillas de cálculo, música, fotos, y cualquier otro archivo
  • espiar al usuario via la cámara o micrófono
  • remplazar el fondo de pantalla del usuario
  • acceder a las palabras claves de los sitios del usuario
  • infectar otros programas en disco rígido con un virus
  • descargar archivos a la máquina del usuario
  • recibir o enviar correo electrónico a nombre del usuario
  • hacer ruidos fuertes o embarazosos con los parlantes

El punto crítico aca no es que el Solitario jamás debería ser permitido el realizar cualquiera de las acciones mencionadas (que claramente no debería), sino que sus creadores _saben_ que jamás debería hacerlas. De esto se deduce que si el sistema tuviera la capacidad por la cual el Solitario indicara esto al momento de su instalación, el Solitario podría renunciar irreversiblemente a ciertos privilegios cuando sea instalado, lo cual limita severamente o destruye totalmente su utilidad para cualquier atacante.

Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:

  • read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files
  • eavesdrop on the user via the camera or microphone
  • replace the user's wallpaper
  • access the user's website passwords
  • infect other programs on the hard drive with a virus
  • download files to the user's machine
  • receive or send e-mail on behalf of the user
  • play loud or embarassing sounds on the speakers

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators _know_ it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.

Las laptops XO de la OLPC proveen justamente dicha facilidad. La instalación de programas no pasa simplemente por la ejecución del instalador, que es a su vez otro programa, sino a traves de un servicio de instalación del sistema que sabe cómo instalar paquetes de programas XO. Durante la instalación, el servicio de instalación le preguntará al paquete por los permisos de seguridad deseados, y posteriormente notificará al Servicio de Seguridad apropiadamente. Una vez instalado, la lista de permisos por programa solamente será modificable por el usuario por medio de la interfaz gráfica.

Un programa benigno como el Solitario simplemente no solicitaría permisos especiales durante su instalación, y llegado su usurpación, sería incapaz de realizar algo particularmente dañino, como alguna de las acciones enumeradas en la lista arriba.

The OLPC XO laptops provide just such a facility. Program installation does not occur through the simple execution of the installer, which is yet another program, but through a system installation service which knows how to install XO program bundles. During installation, the installer service will query the bundle for the program's desired security permissions, and will notify the system Security Service accordingly. After installation, the per-program permission list is only modifiable by the user through a graphical interface.

A benign program such as Solitaire would simply not request any special permissions during installation, and if taken over, would not be able to perform anything particularly damaging, such as the actions from the above list.

Cabe resaltar que dicho sistema _solo_ protege al software benigno. El problema todavía existe con el software intencionalmente malicioso, que bien podría solicitar todos los permisos durante su instalación y abusarlos arbitrariamente cuando sea ejecutado. Para evitar eso es que hacemos ciertos permisos durante la instalación mutuamente excluyentes, lo cual de hecho torna difícil que un programa malicioso solicite un conjunto de permisos que le permitan facilmente realizar acciones maliciosas. Los detalles de dichos mecanismos se encuentra más adelante en este documento.

Como nota final, los programas con firmas criptográficas de la OLPC o de los países individuales pueden evitar los límites a la solicitud de permisos, y de hecho solicitar cualquier conjunto de permisos deseado al momento de su instalación.

It must be noted here that this system _only_ protects benign software. The problem still remains of intentionally malicious software, which might request all available permissions during installation in order to abuse them arbitrarily when run. We address this by making certain initially-requestable permissions mutually exclusive, in effect making it difficult for malicious software to request a set of permissions that easily allow malicious action. Details on this mechanism are provided later in this document.

As a final note, programs cryptographically signed by OLPC or the individual countries may bypass the permission request limits, and request any permissions they wish at installation time.

Ejecución de software: el problema

El modelo de riesgo que intentamos lograr mientras la máquina está corriendo es uno difícil: deseamos tener la capacidad de ejecutar código usualmente sin confianza, al mismo tiempo que limitamos severamente su capacidad de producir daño al sistema.

Muchos de los dispositivos digitales son más vistos o vendidos como embarcados o computadoras administradas que como laptops o máquinas de escritorio personales (un ejemplo es el comunicador PIC de AMD que esquiva el problema del código no confiable completamente, logrando una inmunidad a los virus, malware y spyware permitiendo solamente la ejecución exclusiva de código firmado criptográficamente por el vendedor. En la práctica, esto quiere decir que el usuario esta limitado a la utilización de un conjunto muy limitado de programas provistos por el vendedor, y que no puede desarrollar su propio software o utilizar el de terceros. Si bien esta aproximación a la seguridad limita definitivamente ciertos vectores de ataques, debe ser recalcado que no es una solución definitiva (o silver bullet). Una computadora que no puede ser libremente programada representa una disminución enorme en la utilidad a la cual la mayoría de los usuarios se han acostumbrado y esperan—pero aún si ignoramos esto y nos enfocamos solamente en las calificaciones técnicas de un tal sistema de seguridad, debemos resaltar que casi siempre, las firmas criptográficas de los binarios son revisadas al momento de carga, no continuamente durante su ejecución. Con lo cual, las vulnerabilidades existentes en los binarios provistos por el vendedor aún permiten dañar al sistema. De igual modo, el sistema falla al no proveer ninguna protección contra ataques macro.

The threat model that we are trying to address while the machine is running normally is a difficult one: we wish to have the ability to execute generally untrusted code, while severely limiting its ability to inflict harm to the system.

Many computer devices that are seen or marketed more as embedded or managed computers than personal laptops or desktops (one example is AMD's [[PIC communicator -> http://www.amdboard.com/pic.html]]) purport to dodge the issue of untrusted code entirely, while staving off viruses, malware and spyware by only permitting execution of code cryptographically signed by the vendor. In practice, this means the user is limited to executing a very restricted set of vendor-provided programs, and cannot develop her own software or use software from third party developers. While this approach to security certainly limits available attack vectors, it should be noted it is pointedly not a silver bullet. A computer that is not freely programmable represents a tremendous decrease in utility from what most consumers have come to expect from their computers -- but even if we ignore this and focus merely on the technical qualifications of such a security system, we must stress that almost always, cryptographic signatures for binaries are checked at load time, not continually during execution. Thus exploits for vendor-provided binaries are still able to execute and harm the system. Similarly, this system fails to provide any protection against macro attacks.

Como fue mencionado en la introducción, este modelo de ejecución restringido definitivamente no es una opción para las laptops XO. Aún más, queremos explícitamente incentivar y motivar a nuestros usuarios, los chicos, a participar en una situacion que sería una pesadilla para cualquier experto en seguridad: el compartir fácilmente código entre computadoras.

Como parte de nuestra misión educativa, estamos facilitando a los chicos la capacidad de ver el código del programa que esten corriendo—tanto es así que proveemos la tecla de Ver Código Fuente en el teclado con ese fin—y también estamos haciendoles igualmente fácil el escribir su propio código en Python, nuestro lenguaje de programación por elección. Dado nuestro continuo enfasis en la colaboración como una característica directamente integrada al sistema operativo, el escenario donde un chico desarrolla algún software y desea compartirlo con sus amigos se convierte en algo natural, y que debe ser bien soportado.

As we mention in the introduction, this severely restricted execution model is absolutely not an option for the XO laptops. What's more, we want to explicitly encourage our users, the children, to engage in a scenario certain to give nightmares to any security expert: easy code sharing between computers.

As part of our educational mission, we're making it very easy for children to see the code of the programs they're running -- we even provide a View Source key on the keyboard for this purpose -- and are making it similarly easy for children to write their own code in Python, our programming language of choice. Given our further emphasis on collaboration as a feature integrated directly into the operating system, the scenario where a child develops some software and wishes to share it with her friends becomes a natural one, and one that needs to be well-supported.

Desafortunadamente, el software recibido por medio de un amigo o conocido carece de toda confianza, dado que no existe una correspondencia de la confianza entre personas y software: confiar en un amigo no es, y no puede ser, lo mismo que confiar el código proveniente de dicho amigo. La máquina del amigo puede estar bajo el control de otro, y puede estar intentando enviar código malicioso a todos sus amigos, o el amigo puede querer estar tratando de hacer una jugarreta, o puede haber escrito—ya sea por ignorancia o malicia—software que a veces es malicioso.

Es con éste trasfondo que hemos construído las protecciones de seguridad en la laptop. Una oración capaz de resumir las intenciones de nuestro modelo de seguridad completamente es que "intenta prevenir que el software haga cosas malas". El siguiente capítulo explica las cinco categorías de 'cosas malas' que un software malicioso puede hacer, y el capítulo posterior las protecciones mismas. El capítulo 9 explica el rol de cada protección participa dentro del modelo de riesgos.

Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, or he might have written -- either out of ignorance or malice -- software that is sometimes malicious.

It is against this background that we've constructed security protections for software on the laptop. A one-sentence summary of the intent of our complete software security model is that it "tries to prevent software from doing bad things". The next chapter explains the five categories of 'bad things' that malicious software might do, and the chapter after that our protections themselves. Chapter 9 explains how each protection addresses the threat model.

Modelo de riesgo: las cosas malas que el software puede hacer

En el contexto y propósito de la discusión, existen cinco grandes categorías de "cosas malas" que la ejecución del software puede realizar. Sin un orden particular, el software puede intentar dañar la máquina, vulnerar la privacidad del usuario, dañar la información del usuario, hacer "cosas malas" a otras personas aparte del usuario de la máquina, y por último, suplantar al usuario.

There are five broad categories of "bad things" that running software could do, for the purposes of our discussion. In no particular order, software can attempt to damage the machine, compromise the user's privacy, damage the user's information, do "bad things" to people other than the machine's user, and lastly, impersonate the user.

Dañar la máquina

El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que—siendo un chip flash—tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (re-imaged) y activada para su recuperación.

Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de performance y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo).

Software wishing to render a laptop inoperable has at least five attack vectors. It may try to ruin the machine's BIOS, preventing it from booting. It may attempt to run down the NAND chip used for primary storage, which -- being a flash chip -- has a limited number of write/erase cycles before ceasing to function properly and requiring replacement. Successful attacks on the BIOS or NAND cause hard damage to the machine, meaning such laptops require trained hardware intervention, including part replacement, to restore to operation. The third vector, deleting or damaging the operating system, is an annoyance that would require the machine to be re-imaged and reactivated to run.

Two other means of damaging the machine cause soft damage: they significantly reduce its utility. These attacks are performance degradation and battery drainage (with the side note that variants of the former can certainly cause the latter.)

Cuando nos referimos a la degradación de performance, nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la performance (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la performance general; esta sección será actualizada reflejando dicha información.

When we say performance degradation, we are referring to the over-utilization of any system resource such as RAM, the CPU or the networking chip, in a way that makes the system too slow or unresponsive to use for other purposes. Battery drainage might be a side-effect of such a malicious performance degradation (e.g. because of bypassing normal power saving measures and over-utilization of power-hungry hardware components), or it might be accomplished through some other means. Once we can obtain complete power measurements for our hardware system, we will be aware of whether side channels exist for consuming large amounts of battery power without general performance degradation; this section will be updated to reflect that information.

Vulnerar la privacidad

Prevemos dos modos principales del software vulnerando la privacidad del usuario: el envio no autorizado de información perteneciente al usuario como documentos e imagenes por la red, y el espiar al usuario por medio de la cámara y el micrófono incorporado.

We see two primary means of software compromising user privacy: the unauthorized sending of user-owned information such as documents and images over the network, and eavesdropping on the user via the laptops' built-in camera and microphone.

Dañar los datos del usuario

Un programa malicioso puede intentar borrar o corromper los documentos del usuario, crear una gran cantidad de documentos falsos o llenos de basura que le harían difícil al usuario el encontrar los suyos propios, o atacar a otros servicios del sistema que manipulan datos, como el servicio de búsqueda. De hecho, el atacar al servicio de indexación global puede convertirse en un nuevo canal para el spam, que aparecería constantemente cada vez que el usuario buscase algo en su sistema. Seguramente existen otros vectores de ataque.

A malicious program can attempt to delete or corrupt the user's documents, create large numbers of fake or garbage-filled documents to make it difficult for the user to find her legitimate ones, or attack other system services that deal with data, such as the search service. Indeed, attacking the global indexing service might well become a new venue for spam, that would thus show up every time the user searched for anything on her system. Other attack vectors undoubtedly exist.

Hacer cosas malas a otras personas

El software puede ser malicioso de manera tal que no afecta de un modo directo o importante al usuario u operador de la máquina. Algunos ejemplos incluyen el realizar ataques de denegación de servicio (Denial of Service attack) contra la red inalámbrica o cableada actual (un logro particularmente fácil sobre redes IPv6, sobre las cuales nuestras laptops operarán por defecto), convirtiendose en un relay de spam, uniéndose a un floodnet o algún otro botnet.

Software might be malicious in ways that do not directly or strongly affect the machine's owner or operator. Examples include performing Denial of Service attacks against the current wireless or wired network (a feat particularly easy on IPv6 networks, which our laptops will operate on by default), becoming a spam relay, or joining a floodnet or other botnet.

Suplantar al usuario

Un software malicioso puede intentar abusar de las primitivas de identidad digital del sistema, tales como la firma digital, para enviar mensajes que parecerían provenir del usuario, o abusar de sesiones previamente autenticadas que el usuario puede haber creado hacia recursos privilegiados, tales como el servidor escolar.

Malicious software might attempt to abuse the digital identity primitives on the system, such as digital signing, to send messages appearing to come from the user, or to abuse previously authenticated sessions that the user might have created to privileged resources, such as the school server.

Protecciones

Aquí explicamos el conjunto de protecciones que forman el grueso de la plataforma de seguridad Bitfrost, nuestro nombre para la suma total de los sistemas de seguridad de la laptop. Cada protección enumerada a continuación tiene una etiqueta textual concisa que comienza con la letra P. Dicha etiqueta es puramente una conveniencia para su fácil referencia, y significa tanto la política como el mecanismo de un dado sistema de protección.

Casi todas las protecciones mencionadas pueden ser deshabilitadas por el usuario por medio de una interfaz gráfica. Mientras las protecciones de la laptop se encuentren activas, dicha interfaz no puede ser manipulada por los programas del sistema de ningún modo, ya sea por medio de eventos sintéticos del teclado o el ratón, o la modificación directa del archivo de configuración.

Here, we explain the set of protections that make up the bulk of the Bitfrost security platform, our name for the sum total of the laptop's security systems. Each protection listed below is given a concise uppercase textual label beginning with the letter P. This label is simply a convenience for easy reference, and stands for both the policy and mechanism of a given protection system.

Almost all of the protections we discuss can be disabled by the user through a graphical interface. While the laptop's protections are active, this interface cannot be manipulated by the programs on the system through any means, be it synthetic keyboard and mouse events or direct configuration file modification.

P_BIOS_CORE: proteccion del nucleo de la BIOS

La BIOS de una laptop XO reside en un chip flash SPI de 1MiB, mencionado en la seccion 1.1. Su propósito es el de guardar la información de manufactura acerca de la máquina incluyendo su tupla (NS, UUID), la BIOS propia y su firmware. El reflasheo (reflashing) de la BIOS almacenada esta estrictamente controlado, de modo tal que solamente una imagen BIOS firmada criptográficamente por la OLPC pueda flasheada' al chip. El firmware no realizará el reflasheo si el nivel de la batería es bajo, evitando así que la máquina se apague mientras la operación es llevada a cabo.

Un chico puede solicitar una llave o clave conocida como clave de desarrollador a la OLPC. Esta llave, ligada a la tupla (NS, UUID) de la laptop del chico, le permite al chico flashear cualquier BIOS que desee, de modo tal de permitir a aquellos chicos que se conviertan en desarrolladores avanzados modificar su propio firmware.

The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in Section 1.1. This chip's purpose is to hold manufacturing information about the machine including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the stored BIOS is strictly controlled, in such a way that only a BIOS image cryptographically signed by OLPC can be flashed to the chip. The firmware will not perform a BIOS reflashing if the battery level is detected as low, to avoid the machine powering off while the operation is in progress.

A child may request a so-called developer key from OLPC. This key, bound to the child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she wishes, to accommodate the use case of those children who progress to be very advanced developers and wish to modify their own firmware.

P_BIOS_COPY: Protección de BIOS secundaria

La inclusión de esta protección aún es incierta, y dependerá del tamaño final de la BIOS y el firmware una vez que toda la funcionalidad deseada este incluída. El chip flash SPI provee 1MiB de capacidad; si la BIOS y el firmware pueden ser acomodados en menos de 512KiB, una segunda copia puede ser almacenada en el SPI. Esta copia secundaria sería inmutable (imposible de reflashear) y sería usada para arrancar al sistema en el caso que la BIOS primaria sea inutilizable. Varios factores pueden resultar en dicho estado, principalmente la perdida de energía violenta durante el proceso de flasheo, como ocurriría en el caso de retirar la batería de la máquina, o simplemente un chip SPI defectuoso que no reflashea correctamente. Esta sección será actualizada una vez que se determine la inclusión o no de dicha protección.

The inclusion of this protection is uncertain, and depends on the final size of the BIOS and firmware after all the desired functionality is included. The SPI flash offers 1MB of storage space; if the BIOS and firmware can be made to fit in less than 512KB, a second copy of the bundle will be stored in the SPI. This secondary copy would be immutable (cannot be reflashed) and used to boot the machine in case of the primary BIOS being unbootable. Various factors might lead to such a state, primarily hard power loss during flashing, such as through the removal of the battery from the machine, or simply a malfunctioning SPI chip which does not reflash correctly. This section will be updated once it becomes clear whether this protection can be included.

P_SF_CORE: Protección de archivos del núcleo del sistema

La protección de los archivos del núcleo del sistema impide las modificaciones del sistema almacenado en la memoria flash NAND de la laptop, que es usado como su almacenamiento primario. Cuando se encuentra activa, esta protección controla que ningún proceso altere de cualquier modo los archivos del sistema distribuídos como parte del SO OLPC.

Esta protección no puede ser deshabilitada sin una llave de desarrollador (developer key), mencionada en la Sección 8.1.

The core system file protection disallows modification of the stored system image on a laptop's NAND flash, which OLPC laptops use as primary storage. While engaged, this protection keeps any process on the machine from altering in any way the system files shipped as part of the OLPC OS build.

This protection may not be disabled without a developer key, explained in Section 8.1.

P_SF_RUN: Protección de archivos del sistema ejecutandose

Si bien P_SF_CORE protege a los archivos del sistema *almacenados*, P_SF_RUN protege los archivos del sistema en *ejecución* de ser modificados. Siempre que P_SF_RUN se encuentre activo, en cada inicio, el sistema a ejecutar es cargado directamente de los archivos almacenados, los cuales son marcados como de solo-lectura.

Cuando P_SF_RUN se encuentra desactivado, el procesos de cargado de los archivos del sistema al inicio cambia. En vez de cargar los archivos directamente, una imagen COW (copy-on-write - copia si escribe) es construída a partir de ellos, y los archivos de _esa_ imagen son inicializados como el sistema en ejecución. La imagen COW virtualmente no requiere espacio de almacenamiento adicional en la memoria flash NAND hasta que el usuario realiza modificaciones a los archivos del sistema en ejecución, lo que produce un copiado de los archivos antes de ser cambiados. Estas modificaciones son persistentes entre inicios (booteos), pero sólo se aplica a las copias COW: los archivos del sistema iniciales permanecen intactos.

Whereas P_SF_CORE protects the *stored* system files, P_SF_RUN protects the *running* system files from modification. As long as P_SF_RUN is engaged, at every boot, the running system is loaded directly from the stored system files, which are then marked read-only.

When P_SF_RUN is disengaged, the system file loading process at boot changes. Instead of loading the stored files directly, a COW (copy on write) image is constructed from them, and system files from _that_ image are initialized as the running system. The COW image uses virtually no additional storage space on the NAND flash until the user makes modifications to her running system files, which causes the affected files to be copied before being changed. These modifications persist between boots, but only apply to the COW copies: the underlying system files remain untouched.

Si se reactiva el P_SF_RUN tras su deshabilitación, los archivos utilizados para el inicio del sistema cambian nuevamente; los archivos son cargados a la memoria sin su imagen COW intermedia, y marcados como de solo lectura.

No hay interdependencia entre P_SF_CORE y P_SF_RUN. Si P_SF_CORE está deshabilitado y los archivos del sistema son modificados, pero P_SF_RUN está habilitado, despues del reinicio ninguna modificación al sistema en ejecución sera permitidos, más allá del hecho que los archivos iniciales hayan sido cambiados de la versión original del OS de la OLPC.

If P_SF_RUN is re-engaged after being disabled, the boot-time loading of system files changes again; the system files are loaded into memory directly with no intermediate COW image, and marked read-only.

P_SF_CORE and P_SF_RUN do not inter-depend. If P_SF_CORE is disengaged and the stored system files are modified, but P_SF_RUN is engaged, after reboot no modification of the running system will be permitted, despite the fact that the underlying system files have changed from their original version in the OLPC OS build.

P_NET: Política de protección de red

La utilización de la red por parte de un programa puede estar limitado de las siguientes maneras:

  • Restricción Booleana (si/no) de uso de red
  • Utilización del ancho de banda por medio de token-bucket y ráfagas
  • Límite a la velocidad de transmisión
  • Restricciones sobre el destino de los paquetes por nombre, IP y puerto(s)
  • Horarios de acceso a la red
  • Límite de velocidad por horarios o días
  • Restricción como servidor (apertura y escucha de un socket), Booleano y por puerto

Por defecto, se aplicarán límites razonables de velocidad y volúmen de descarga a todos los programas carentes de firmas. De ser necesario, se pueden aplicar diferentes políticas al tráfico dirigido a la malla o los puntos de acceso (access points). Restricciones adicionales podrían ser agregadas a esta lista a medida que completemos la evaluación de los requerimientos de política de red.

Each program's network utilization can be constrained in the following ways:

  • Boolean network on/off restriction
  • token-bucketed bandwidth throttling with burst allowance
  • connection rate limiting
  • packet destination restrictions by host name, IP and port(s)
  • time-of-day restrictions on network use
  • data transfer limit by hour or day
  • server restriction (can bind and listen on a socket), Boolean and per-port

Reasonable default rate and transfer limits will be imposed on all non-signed programs. If necessary, different policies can apply to mesh and access point traffic. Additional restrictions might be added to this list as we complete our evaluation of network policy requirements.

P_NAND_RL: Protección de escritura/borrado de la NAND

Un acelerador tipo token-bucket con límites de ráfagas será usado por el sistema de archivos JFF2 sobre la memoria flash NAND, que simplemente comenzará a demorar las operaciones de escritura/borrado generadas por un programa en particular después que su balde (bucket) se haya agotado. Actualmente se encuentra bajo consideración si una demora tal produzca un impacto exponencial, aunque no se ha tomado ninguna decisión y se esperan resultados de pruebas reales.

Una interface con el núcleo (kernel) permitirá el acceso a los niveles de llenado de los baldes (buckets) por programa hacia el espacio del usuario, permitiendo así la creación de más políticas aplicables sobre el espacio de usuario, tales como el cerrado de programas cuyos baldes permanezcan agotados durante mucho tiempo. Estas políticas serán mantenidas y ejecutadas por el Servicio de Seguridad del sistema, un programa en el espacio del usuario privilegiado.

A token-bucketed throttle with burst allowance will be in effect for the JFFS2 filesystem used on the NAND flash, which will simply start delaying write/erase operations caused by a particular program after its bucket is drained. It is currently being considered that such a delay behaves as an exponential backoff, though no decision has yet been made, pending some field testing.

A kernel interface will expose the per-program bucket fill levels to userspace, allowing the implementation of further userspace policies, such as shutting down programs whose buckets remain drained for too long. These policies will be maintained and enforced by the system Security Service, a privileged userspace program.

P_NAND_QUOTA: Cuota de NAND

Con el objeto de prevenir ataques de agotamiento de disco, a los programas se les otorga un espacio de borrador (scratch) limitado para guardar su configuración y archivos temporales, asi como varios caches. Actualmente, el límite es de 5MiB. Adicionalmente, se impondrán límites sobre los inodes y dirents dentro del espacio de borrador (scratch), con valores a determinar.

Esto no incluye el espacio para los documentos de usuario creados o manipulados por el programa, que son almacenados por medio del almacén de archivos (file store). Dicho almacén de archivos (file store) será explicado más adelante.

To prevent disk exhaustion attacks, programs are given a limited scratch space in which they can store their configuration and temporary files, such as various caches. Currently, that limit is 5MB. Additionally, limits will be imposed on inodes and dirents within that scratch space, with values to be determined.

This does not include space for user documents created or manipulated by the program, which are stored through the file store. The file store is explained in a later section.

P_MIC_CAM: Protección de cámara y micrófono

En un primer nivel, la cámara y micrófono incorporados se encuentran protegidos por el hardware: existe un LED al costado de cada uno, que se encenderá (vía hardware, sin control de software) cuando dicho elemento se encuentre activo. Esto provee un indicador simple y obvio de cuando son usados. Su encendido inesperado será una señal ante cualquier intento de espionaje.

El segundo nivel es que el uso de la cámara y el micrófono requieren la solicitud por parte del programa de un permiso especial al momento de instalación como fue descripto en el Capítulo 5. Este permiso sin embargo no le permite a un programa acceder y prender instantáneamente la cámara o el micrófono. Solamente le permite al programa _preguntarle_ al usuario si puede encender la cámara, el micrófono o ambos.

At the first level, our built-in camera and microphone are protected by hardware: an LED is present next to each, and is lit (in hardware, without software control) when the respective component is engaged. This provides a very simple and obvious indication of the two being used. The LEDs turning on unexpectedly will immediately tip off the user to potential eavesdropping.

Secondly, the use of the camera and microphone require a special permission, requested at install-time as described in Chapter 5, for each program wishing to do so. This permission does not, however, allow a program to instantly turn on the camera and microphone. Instead, it merely lets the program _ask_ the user to allow the camera or microphone (or both) to be turned on.

Esto quiere decir que cualquier programa benigno que haya sido subvertido pero que no se haya declarado como utilizador de la cámara o el micrófono no puede ser utilizado para activarlos, NI para solicitarle al usuario que lo haga!

Los programas que se hayan declarado a sí mismos como requeridores de dichos privilegios (ej: una aplicación de videoconferencia o VoIP) pueden instruir al sistema para que le solicite al usuario su permiso de activar la cámara o el micrófono, y si la solicitud es otorgada, el programa tendrá permiso de manipular el componente por un tiempo limitado, ej: 30 minutos. Transcurrido dicho plazo de tiempo, se le deberá solicitar nuevamente al usuario su permiso.

This means that any benign programs which are taken over but haven't declared themselves as needing the camera or microphone cannot be used neither to turn on either, NOR to ask the user to do so!

Programs which have declared themselves as requiring those privileges (e.g. a VOIP or videoconferencing app) can instruct the system to ask the user for permission to enable the camera and microphone components, and if the request is granted, the program is granted a timed capability to manipulate the components, e.g. for 30 minutes. After that, the user will be asked for permission again.

Como fue mencionado en el Capítulo 5, los programas firmados criptográficamente por una autoridad de confianza estarán exentos de necesitar el pedir permiso para manipular los componentes, pero dada la presencia de los LEDs indicadores de su estado, el potencial para su abuso es bastante bajo.

As mentioned in Chapter 5, programs cryptographically signed by a trusted authority will be exempt from having to ask permission to manipulate the components, but because of the LEDs which indicate their status, the potential for abuse is rather low.

P_CPU_RL: Limitando la CPU

Los programas activos en primera plana (foreground) pueden utilizar toda la potencia de la CPU. Sin embargo, los programas en el fondo (background), no pueden usar mas que una cantidad fija—actualmente estamos pensando en usar un 10%—a no ser que tengan un permiso especial por parte del usuario.

La IU de Sugar en las laptops XO no soportan ventanas superpuestas: solo ventanas de aplicaciones maximizadas son soportadas. Cuando nos referimos a la ejecución en primer plano o fondo, nos estamos refiriendo a los programas que estan, o no, mostrando ventanas en la pantalla en un dado momento.

Foreground programs may use all of the machine's CPU power. Background programs, however, may use no more than a fixed amount -- currently we're looking to use 10% -- unless given a special permission by the user.

The Sugar UI environment on the XO laptops does not support overlapping windows: only maximized application windows are supported. When we talk about foreground and background execution, we are referring to programs that are, or are not, currently displaying windows on the screen.

P_RTC: Protección del reloj de tiempo real

Un desplazamiento de tiempo relativo al RTC (real time clock - reloj de tiempo real) es mantenido para cada programa en ejecución, y se le permite al programa cambiar dicho desplazamiento de forma arbitraria. Esto satisface las necesidades de ciertos programas de cambiar el reloj del sistema que usan (ya tenemos un programa de música que debe sincronizarse con un margen de 10ms con cualquier otra máquina con la cual esten tocando música) evitando impactar en otros programas del sistema.

A time offset from the RTC is maintained for each running program, and the program is allowed to change the offset arbitrarily. This fulfills the need of certain programs to change the system time they use (we already have a music program that must synchronize to within 10ms with any machines with which it co-plays a tune) while not impacting other programs on the system.

P_DSP_BG: Permiso de sonido de fondo

Este es un permiso, solicitable al momento de instalación, que habilita al programa a generar audio cuando no se encuentra en primer plano (foreground). Su objetivo es permitir que los programas benignos sean inmunes a ser utilizados para generar sonidos molestos o embarazosos en el caso de ser subvertidos.

This is a permission, requestable at install-time, which lets the program play audio while it isn't in the foreground. Its purpose is to make benign programs immune to being used to play annoying or embarrassing loud sounds if taken over.

P_X: Protección del sistema de ventanas X

Cuando es asignado manualmente a un programa por medio de la interfaz gráfica de seguridad, éste permiso habilita a un programa a enviar eventos de ratón sintéticos a otro programa. Su objetivo es permitir el uso de software de accesibilidad como un teclado-en-pantalla. Este permiso NO es solicitable al momento de instalación, y por lo tanto deber ser manualmente otorgado por el usuario por medio de la interz gráfica, a no ser que el software que quiera usarlo este firmado criptográficamente por una autoridad de confianza.

Sin este permiso, los programas no pueden espiar o simular los eventos de otros, lo cual inhabilita software de grabado de teclado (key logging) o ataques basados en una manipulación sofisticada de eventos sintéticos, donde un software malicioso actúa como un control remoto para algún otro programa.

When manually assigned to a program by the user through a graphical security interface, this permission lets a program send synthetic mouse X events to another program. Its purpose is to enable the use of accessibility software such as an on-screen keyboard. The permission is NOT requestable at install-time, and thus must be manually assigned by the user through a graphical interface, unless the software wishing to use it is cryptographically signed by a trusted authority.

Without this permission, programs cannot eavesdrop on or fake one another's events, which disables key logging software or sophisticated synthetic event manipulation attacks, where malicious software acts as a remote control for some other running program.

P_IDENT: Servicio de identidad

El servicio de identidad es el responsable de generar el par de llaves ECC durante el primer inicio, mantener al par seguro, y responder a los pedidos de inicio de sesiones firmadas o encriptadas con otras máquinas en la red.

Con el uso del servicio de identidad, todas las interacciones o comunicaciones entre pares (e-mails, mensajes instantáneos, y similares) pueden ser firmados criptográficamente para mantener su integridad aún si son ruteados a través de pares potencialmente maliciosos en la malla, y también puede ser encriptado en aquellos países que no represente un problema legal.

The identity service is responsible for generating an ECC key pair at first boot, keeping the key pair secure, and responding to requests to initiate signed or encrypted sessions with other networked machines.

With the use of the identity service, all digital peer interactions or communication (e-mails, instant messages, and so forth) can be cryptographically signed to maintain integrity even as they're routed through potentially malicious peers on the mesh, and may also be encrypted in countries where this does not present a legal problem.

P_SANDBOX: Cárceles de programas

Un programa en la XO comienza en un chroot fortificado, similar a una cárcel BSD, donde la raíz visible del sistema de archivos es el su propio espacio de borrador (scratch). Usualmente no tiene acceso a las rutas de acceso del sistema tales como /proc o /sys, no puede ver otros programas en el sistema o sus espacios de borrador (scratch). No puede acceder a los documentos del usuario directamente, sino a traves del servicio de almacén de archivos (file store service), explicado en la siguiente sección.

El espacio de borrador (scratch) de cada programa posee tres directorios escribibles, llamados 'tmp', 'conf', y 'data'. El programa es libre de usarlos para archivos temporales, de configuración, y datos (recursos) respectivamente. El resto del espacio de borrador (scratch) es inmutable; el programa no puede modificar sus binarios o archivos de recursos principales. Este modelo asegura que un programa pueda ser restaurado a su instalación de base por medio de la eliminación del contenido de esos tres directorios escribibles, y que pueda ser desinstalado en su totalidad eliminando su directorio.

A program on the XO starts in a fortified chroot, akin to a BSD jail, where its visible filesystem root is only its own constrained scratch space. It normally has no access to system paths such as /proc or /sys, cannot see other programs on the system or their scratch spaces, and only the libraries it needs are mapped into its scratch space. It cannot access user documents directly, but only through the file store service, explained in the next section.

Every program scratch space has three writable directories, called 'tmp', 'conf', and 'data'. The program is free to use these for temporary, configuration, and data (resource) files, respectively. The rest of the scratch space is immutable; the program may not modify its binaries or core resource files. This model ensures that a program may be restored to its base installation state by emptying the contents of the three writable directories, and that it can be completely uninstalled by removing its bundle (scratch space) directory.

P_DOCUMENT: Servicio de almacenamiento de archivos

A diferencia de las máquinas tradicionales, los documentos del usuario en las laptops XO no son guardados directamente en el sistema de archivos. En su lugar, son leídos y guardados por medio de un servicio de almacenamiento de archivos, que provee una interfaz orientada-a-objetos a los documentos del usuario. El diseño, en términos amplios y generales, es similar a WinFS de Microsoft, ya que el almacén permite una rica asociación de metadata manteniendo la semántica de lectura y escritura (read()/write()) tradicionales de UNIX para la manipulación del contenido del archivo.

Los programas en la XO no pueden hacer uso de la función open() (abrir) para abrir arbitrariamente un documento del usuario en el sistema, ni inspeccionar la lista de documentos disponibles, ej: examinando los contenidos de un directorio. En su lugar, cuando un programa desea abrir un documento del usuario, debe solicitarle al sistema que le presente al usuario un dialogo de 'apertura de archivo'. Una versión copia-si-escribe (copy-on-write) del archivo así seleccionado simplemente "aparecerá" en el espacio de borrador (scratch) del programa junto con un mensaje informandole de su ruta de acceso dentro de dicho espacio de borrador (scratch).

Unlike with traditional machines, user documents on the XO laptop are not stored directly on the filesystem. Instead, they are read and stored through the file store service, which provides an object-oriented interface to user documents. Similar in very broad terms to the Microsoft WinFS design, the file store allows rich metadata association while maintaining traditional UNIX read()/write() semantics for actual file content manipulation.

Programs on the XO may not use the open() call to arbitrarily open user documents in the system, nor can they introspect the list of available documents, e.g. through listing directory contents. Instead, when a program wishes to open a user document, it asks the system to present the user with a 'file open' dialog. A copy-on-write version of the file that the user selects is also mapped into this scratch space -- in effect, the file just "appears", along with a message informing the program of the file's path within the scratch space.

Unix permite el pasaje de descriptores de archivos (fds - file descriptors) a traves de domain sockets de Unix, con lo cual una alternativa de P_DOCUMENT sería pasar el descriptor (fd) de dicho archivo. Hemos decidido no usar dicha alternativa ya que la comunicación con el almacén de archivos no se lleva a cabo directamente sobre domain sockets de Unix, sino por medio de los mecanismos del D-BUS IPC, y porque la manipulación directa de los descriptores (fds) puede ser complicada en lenguajes de alto nivel.

Los programas benignos no son afectados negativamente por esta necesidad de usar al almacén de archivos para acceder a los documentos, particularmente porque en general no les interesa mostrar sus propios diálogos de apertura de archivos (con la rara excepción de aquellos que los especializan ej: permitir una vista en miniatura; por el momento, no esta siendo considerado este caso de uso).

Sin embargo, los programas malignos, pierden una importante capacidad de violar la privacidad del usuario o dañar sus datos, ya que todo acceso a los documentos requiere del consentimiento explícito por parte del usuario.

Unix supports the passing of file descriptors (fds) through Unix domain sockets, so an alternative implementation of P_DOCUMENT would merely pass in the fd of the file in question to the calling program. We have elected not to pursue this approach because communication with the file store service does not take place directly over Unix domain sockets, but over the D-BUS IPC mechanism, and because dealing with raw fds can be a hassle in higher-level languages.

Benign programs are not adversely impacted by the need to use the file store for document access, because they generally do not care about rendering their own file open dialogs (with the rare exception of programs which create custom dialogs to e.g. offer built-in file previews; for the time being, we are not going to support this use case).

Malicious programs, however, lose a tremendous amount of ability to violate the user's privacy or damage her data, because all document access requires explicit assent by the user.

P_DOCUMENT_RO

Ciertos tipos de software, como un programa de visualizacion de fotos, necesita el acceso a todos los documentos de un cierto tipo (ej: imágenes) con el fin de cumplir su función. Esto entra en conflicto directo con la protección P_DOCUMENT que requiere el consentimiento del usuario para cada documento a abrir—en este caso, cada foto.

Para resolver este dilema, nos debemos preguntar: "de que estamos tratando de proteger al usuario?" La respuesta, en este caso, es de un programa malicioso que solicita el permiso de leer todas las imagenes, o todos los archivos de texto, o todos los e-mails, y despues enviar dichos documentos por la red a un atacante o su publicación, vulnerando seriamente la privacidad del usuario.

Certain kinds of software, such as photo viewing programs, need access to all documents of a certain kind (e.g. images) to fulfill their desired function. This is in direct opposition with the P_DOCUMENT protection which requires user consent for each document being opened -- in this case, each photo.

To resolve the quandary, we must ask ourselves: "from what are we trying to protect the user?". The answer, here, is a malicious program which requests permission to read all images, or all text files, or all e-mails, and then sends those documents over the network to an attacker or posts them publicly, seriously breaching the user's privacy.

Resolvemos esto permitiendo que un programa solicite permisos de solo-lectura para un tipo de documento (ej: imagen, audio, texto, e-mail) durante el proceso de instalación, pero haciendo dicho permiso (P_DOCUMENT_RO) mutuamente excluyente con el solicitar cualquier tipo de acceso a la red. En otras palabras, un programa de visualización de fotos, normalmente no tiene ninguna necesidad o interés en conectarse a Internet.

Como con otros permisos, el usuario puede habilitar el permiso de red a un dado programa que haya solicitado P_DOCUMENT_RO durante su instalación, evitando así la exclusión mutua.

We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet.

As with other permissions, the user may assign the network permission to a program which requested P_DOCUMENT_RO at install, bypassing the mutual exclusion.

P_DOCUMENT_RL: Limitando el ritmo de almacenamiento de archivos

El almacén de archivos (file store) no permite a los programas guardar nuevos archivos o nuevas versiones de archivos viejos con una frecuencia mayor a un dado valor, ej: una vez cada 30 segundos.

The file store does not permit programs to store new files or new versions of old files with a frequency higher than a certain preset, e.g. once every 30 seconds.

P_DOCUMENT_BACKUP: Servicio de respaldo de archivos

Cuando se este dentro del alcance de servidores que se anuncien a sí mismos como oferentes del servicio de respaldo (backup), la laptop realizará automáticamente las copias de respaldo incrementales de los documentos del usuario que podrán ser recuperados con posterioridad. Dado el deseo de evitar que un chico tenga que generar una nueva identidad digital si alguna vez su laptop es extraviada, robada o destruida, por defecto el par de llaves ECC del chico tambien son copiadas al servidor de respaldo. Dado que la llave privada de un chico normalmente no está protegida con una palabra clave (password), robando el servidor primario de respaldo (normalmente el servidor escolar) le ofrece al ladrón la habilidad de suplantar a cualquier chico en el sistema.

Por el momento, consideramos que esto es un riesgo aceptable. Aunque debería ser mencionado que la llave privada sólo será copiada al servidor de respaldo primario—usualmente en la escuela—y no a cualquier servidor que se anuncia como proveedor del servicio de respaldo. Aún más, en cualquiera de los servidores de respaldo no-primarios, solamente se guardarán versiones incrementales encriptadas.

When in range of servers that advertise themselves as offering a backup service, the laptop will automatically perform incremental backups of user documents which it can later retrieve. Because of the desire to avoid having to ask children to generate a new digital identity if their laptop is ever lost, stolen or broken, by default the child's ECC keypair is also backed up to the server. Given that a child's private key normally has no password protection, stealing the primary backup server (normally the school server) offers the thief the ability to impersonate any child in the system.

For now, we deem this an acceptable risk. We should also mention that the private key will only be backed up to the primary backup server -- usually in the school -- and not any server that advertises itself as providing backup service. Furthermore, for all non-primary backup servers, only encrypted version of the incremental backups will be stored.

P_THEFT: Protección anti-robo

El proyecto de la OLPC ha recibido solicitudes muy firmes por parte de algunos países considerando unirse al programa para la inclusión de un poderoso servicio anti-robo a fin de disuadir a la mayoría de los ladrones.

Proveemos dicho servicio para que los países interesados puedan habilitarlo en sus laptops. Funciona por medio de la ejecución de un proceso privilegiado que no puede ser deshabilitado o finalizado aún por el administrador (root), un demonio (daemon) anti-robo que al detectar un acceso a Internet, realiza una llamada-a-casa (call-home)—no más de una vez al día—a los servidores anti-robo nacionales. Al hacerlo, es capaz de usar al NTP (network time protocol—protocolo de tiempo de red) de manera segura para ajustar el reloj de tiempo real (RTC - real time clock) de la máquina a la hora actual, y despues obtener un plazo criptográfico para seguir corriendo durante una dada cantidad de tiempo, ej: 21 días. La duración del plazo es controlada por cada país.

The OLPC project has received very strong requests from certain countries considering joining the program to provide a powerful anti-theft service that would act as a theft deterrent against most thieves.

We provide such a service for interested countries to enable on the laptops. It works by running, as a privileged process that cannot be disabled or terminated even by the root user, an anti-theft daemon which detects Internet access, and performs a call-home request -- no more than once a day -- to the country's anti-theft servers. In so doing, it is able to securely use NTP to set the machine RTC to the current time, and then obtain a cryptographic lease to keep running for some amount of time, e.g. 21 days. The lease duration is controlled by each country.

La tupla (NS, UUID) de una laptop robada será reportada al cuerpo responsable del servicio anti-robo encargado del proyecto de la OLPC en el país. La laptop será así marcada como robada en la base de datos central nacional.

Un ladrón puede intentar varias cosas con la laptop: usarla para conectarse a la Internet, aislarla de cualquier red e utilizarla de modo aislado, o usar sus componentes como piezas.

A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC oversight body in charge of the anti-theft service. The laptop will be marked stolen in the country's master database.

A thief might do several things with a laptop: use it to connect to the Internet, remove it from any networks and attempt to use it as a standalone machine, or take it apart for parts.

En el primer caso, el daemon anti-robo se enteraría que la laptop ha sido robada tan pronto como se conecte a Internet, y llevará a cabo un apagado 'duro' (hard shutdown) y bloqueará la máquina de modo tal de necesitar una activación, mencionada anteriormente, para volver a funcionar.

No esperamos que las máquinas sean un blanco apetecible para la reventa de partes. Exceptuando la pantalla especial, todas las otras partes de las laptops XO se encuentran soldadas a la placa madre (motherboard).

In the former case, the anti-theft daemon would learn that the laptop is stolen as soon as it's connected to the Internet, and would perform a hard shutdown and lock the machine such that it requires activation, described previously, to function.

We do not expect the machines will be an appealing target for part resale. Save for the custom display, all valuable parts of the XO laptops are soldered onto the motherboard.

Considerando el caso donde una máquina robada es usada como una computadora personal pero sin estar conectada a Internet, el daemon anti-robo procederá a apagar y bloquear la máquina si su plazo criptográfico alguna vez expirase. En otras palabras, si el país opera con plazos de 21 días, una laptop normal, no-robada, tendrá su plazo renovado por 21 días cada día que se conecte a Internet. Pero si la máquina no se conecta a Internet durante 21 días, se apagará y bloqueará.

Dado que esto podría representar ciertos problemas en algunos países con un acceso intermitente a Internet, los plazos pueden ser bastante largos (siguen siendo una disuasión efectiva aún con una duración de tres meses), o pueden ser prolongados por medio de la conexion de un disco USB al servidor de activación. Por ejemplo, un país puede otorgar plazos de tres semanas, pero si una escuela sufriese un desperfecto en su antena satelital, el cuerpo responsable del país de la OLPC puede enviar por correo un disco USB al responsable de la distribución en la escuela, el cual una vez conectado al servidor escolar, y de un modo transparente, extiende el plazo para cada laptop referenciada por un dado período de tiempo.

To address the case where a stolen machine is used as a personal computer but not connected to the Internet, the anti-theft daemon will shut down and lock the machine if its cryptographic lease ever expires. In other words, if the country operates with 21-day leases, a normal, non-stolen laptop will get the lease extended by 21 days each day it connects to the Internet. But if the machine does not connect to the Internet for 21 days, it will shut down and lock.

Since this might present a problem in some countries due to intermittent Internet access, the leases can either be made to last rather long (they're still an effective theft deterrent even with a 3 month duration), or they can be manually extended by connecting a USB drive to the activation server. For instance, a country may issue 3-week leases, but if a school has a satellite dish failure, the country's OLPC oversight body may mail a USB drive to the school handler, which when connected to the school server, transparently extends the lease of each referenced laptop for some period of time.

El sistema anti-robo no puede ser evitado mientras el P_SF_CORE este habilitado (y su deshabilitación requiere de una llave de desarrollador). Esto, de hecho, quiere decir que un chico es libre de realizar cualquier modificación sobre su espacio de usuario en su máquina (por medio de la desactivación del P_SF_RUN sin necesidad de la llave de desarrollador), pero no puede cambiar el núcleo (kernel) en ejecución sin solicitar la llave. El proceso de entrega de llaves tiene incorporado una demora de 14 días con el objeto de permitir demoras en el reporte de robos a traves del sistema, y sólo es emitida si la máquina no ha sido reportada como robada al finalizar dicho periodo de tiempo.

The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and disabling it requires a developer key). This, in effect, means that a child is free to do any modification to her machine's userspace (by disabling P_SF_RUN without a developer key), but cannot change the running kernel without requesting the key. The key-issuing process incorporates a 14-day delay to allow for a slow theft report to percolate up through the system, and is only issued if the machine is not reported stolen at the end of that period of time.

P_SERVER_AUTH: Autentificación transparente y segura a un servidor autorizado

Cuando se este dentro del alcance de un servidor autorizado (ej: uno provisto por la OLPC o el país), la laptop puede responder de manera segura a un desafío de autentificación (authentication challenge) con su tupla (NS, UUID). Además de servirle a la escuela como un mecanismo de control de acceso a la red—sabemos de ciertas escuelas, por ejemplo, no desean proveer acceso a Internet a sus ex-alumnos, solamente a los actuales—esta autentificación puede desbloquear ciertos servicios extras como copias de respaldo y el acceso servicios de identidad digital descentralizados tales como OpenID.

OpenID es particularmente interesante para la OLPC, dado que puede ser usado para perpetuar un acceso sin palabras claves aún con sitios que normalmente requieren autentificación, siempre y cuando soporte OpenID. El modo de uso actualmente más común entre los proveedores del servicio de OpenID es el de requerir una autentificación al usuario por medio de una palabra clave. Con un proveedor de servicio OpenID corriendo en el servidor escolar (o algún otro servidor de confianza), los logins a sitios que funcionan con OpenID simplemente ocurrirán de modo transparente, dado que la máquina del chico ya ha sido autenticada en el fondo por P_SERVER_AUTH.

When in wireless range of a trusted server (e.g. one provided by OLPC or the country), the laptop can securely respond to an authentication challenge with its (SN, UUID) tuple. In addition to serving as a means for the school to exercise network access control -- we know about some schools, for instance, that do not wish to provide Internet access to alumni, but only current students -- this authentication can unlock extra services like backup and access to a decentralized digital identity system such as OpenID.

[[OpenID -> http://en.wikipedia.org/wiki/OpenID]] is particularly appealing to OLPC, because it can be used to perpetuate passwordless access even on sites that normally require authentication, as long as they support OpenID. The most common mode of operation for current OpenID identity providers is to request password authentication from the user. With an OpenID provider service running on the school server (or other trusted servers), logins to OpenID-enabled sites will simply succeed transparently, because the child's machine has been authenticated in the background by P_SERVER_AUTH.

(A futuro) P_PASSWORD: Proteccion con clave

Todavía no ha sido definido si esta protección entrará en la generación 1 de las laptops XO. Cuando sea instrumentada, sin embargo, le permitirá al usuario determinar un palabra clave (password) para ser usada con su identidad digital, iniciar la máquina y el acceso a algunos de sus archivos.

It is unclear whether this protection will make it in to generation 1 of the XO laptops. When implemented, however, it will allow the user to set a password to be used for her digital identity, booting the machine, and accessing some of her files.

Considerando el modelo de riesgos

Aquí examinamos las cinco categorías de "cosas malas" que el software puede hacer segun el Capítulo 7, y explicamos como las protecciones enumeradas en el Capítulo 8 ayudan. Las siguientes secciones son dadas en el mismo orden que en el modelo de riesgos del Capítulo 7.

We look at the five categories of "bad things" software can do as listed in Chapter 7, and explain how protections listed in Chapter 8 help. The following sections are given in the same order as software threat model entries in Chapter 7.

Dañando la máquina

P_BIOS_CORE se asegura que la BIOS solo pueda ser actualizada por imagenes BIOS provenientes de fuentes confiables. Un chico con una llave de desarrollador puede flashear cualquier BIOS deseada, aunque si somos capaces de instrumentar P_BIOS_COPY, la máquina permanecerá operacional aun si el chico flashea una BIOS rota o inservible. Los programas que buscan dañar al SO no lo pueden hacer a causa de P_SANDBOX y P_SF_RUN. Llegado el caso en el que usuario con P_SF_RUN deshabilitado fuese engañado para dañar su SO o lo hace accidentalmente, P_SF_CORE le permite restaurar al estado inicial (activación) al momento de re-iniciar o arrancar.

Los programas que intentan arruinar la NAND consumiendo los ciclos de escritura/borrado son controlados por medio de P_NAND_RL, y los ataques de agotamiento de disco en el espacio de borrador (scratch) son mantenidos bajo control por P_NAND_QUOTA. Los ataques de agotamiento del disco con documentos del usuario son mucho mas difíciles por P_DOCUMENT_RL.

Los programas que sobrecargan la CPU son mantenidos en linea con P_CPU_RL. Y los de redes son controlados por medio de politicas P_NET.

P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from trusted sources. A child with a developer key may flash whichever BIOS she pleases, though if we are able to implement P_BIOS_COPY, the machine will remain operational even if the child flashes a broken or garbage BIOS. Programs looking to damage the OS cannot do so because of P_SANDBOX and P_SF_RUN. Should a user with P_SF_RUN disabled be tricked into damaging her OS or do so accidentally, P_SF_CORE enables her to restore her OS to its initial (activated) state at boot time.

Programs trying to trash the NAND by exhausting write/erase cycles are controlled through P_NAND_RL, and disk exhaustion attacks in the scratch space are curbed by P_NAND_QUOTA. Disk exhaustion attacks with user documents are made much more difficult by P_DOCUMENT_RL.

CPU-hogging programs are reined in with P_CPU_RL. Network-hogging programs are controlled by policy via P_NET.

Vulnerando la privacidad

La lectura arbitraria y/o el envío de los documentos del usuario por la red es controlado por P_DOCUMENT, mientras que el marcar los documentos con el programa que los creó permite controlar el escenario en el cual un programa malicioso intenta hacer spam en el servicio de búsqueda. Los resultados de un único programa en las búsquedas puede ser ocultado (permanentemente), o eliminados del índice completamente.

P_DOCUMENT_RO protege al usuario en forma adicional al evitar una violación a la privacidad en gran escala por software que pretende ser un "visualizador" de un amplio grupo de documentos.

P_MIC_CAM hace que el espiar al usuario sea difícil, y P_X hace extremadamente difícil el robar palabras claves u otro tipo de información sensible, o monitorear el ingreso de texto desde otros programas en ejecución.

Arbitrary reading and/or sending of the user's documents over the network is curbed by P_DOCUMENT, while tagging documents with the program that created them addresses the scenario in which a malicious program attempts to spam the search service. Search results from a single program can simply be hidden (permanently), or removed from the index completely.

P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches by software that purports to be a "viewer" of some broad class of documents.

P_MIC_CAM makes eavesdropping on the user difficult, and P_X makes it very hard to steal passwords or other sensitive information, or monitor text entry from other running programs.

Dañando los datos del usuario

El almacén de archivos (file store) no permite a los programas sobre-escribir objetos tales como e-mail y texto que no sean blobs binarios opacos. En vez de ello, una nueva versión es guardada, y el almacén de archivos (file store) presenta una lista completa con el histórico de versiones. Esto permite una amplia protección de los documentos contra borrado o corrupción a manos de programas maliciosos—que, por supuesto, tuvieron que obtener el permiso del usuario para mirar el archivo en cuestion para comenzar, como es explicado por P_DOCUMENT.

En el caso de los blobs—videos, música, imagenes—un programa malicioso con el cual el usuario específicamente abra un archivo dado posee la capacidad de corromperlo o borrarlo. Sin embargo, no podemos proteger al usuario de si mismo. Vale la pena destacar que el borrado esta limitado _únicamente_ a los archivos que el usuario ha abierto explícitamente. Más aún, P_DOCUMENT_BACKUP permite una salida aún en dicha situación, suponiendo que la máquina haya tenido la oportunidad de cruzarse con un servidor de respaldo (backup) (los servidores escolares de la OLPC se anuncian como tales).

File store does not permit programs to overwrite objects such as e-mail and text which aren't opaque binary blobs. Instead, only a new version is stored, and the file store exposes a list of the full version history. This affords a large class of documents protection against deletion or corruption at the hands of a malicious program -- which, of course, had to obtain the user's permission to look at the file in question in the first place, as explained in P_DOCUMENT.

For binary blobs -- videos, music, images -- a malicious program in which the user specifically opens a certain file does have the ability to corrupt or delete the file. However, we cannot protect the user from herself. We point out that such deletion is constrained to _only_ those files which the user explicitly opened. Furthermore, P_DOCUMENT_BACKUP allows a final way out even in such situations, assuming the machine came across a backup server (OLPC school servers advertise themselves as such).

Haciendo cosas malas a otros

Las laptops XO serán poco apetecibles como relays de spam o clientes de floodnet dado los límites impuestos a todos los programas carentes de firmas digitales por el P_NET. A pesar del atractivo que supone la escala de distribución de las XOs para spamming o flooding, suponemos que la restricción de bajo uso de la red para software carentes de confianza—junto a la gran dificultad de escribir gusanos (worms) o software auto-propagante para las máquinas XO—reducirá drásticamente esta preocupación.

XO laptops will be quite unattractive as spam relays or floodnet clients due to network rate and transfer limits imposed on all non-signed programs by P_NET. Despite the appeal of the XO deployment scale for spamming or flooding, we expect that a restriction to generally low-volume network usage for untrusted software -- coupled with the great difficulty in writing worms or self-propagating software for XO machines -- will drastically reduce this concern.

Suplantando al usuario

El diseño del servicio de identidad, P_IDENT, no permite a los programas entrar jamás en contacto con el par de llaves o claves criptográficas del usuario, ni inyectar información en sesiones ya abiertas que esten usando el servicio de identidad para firmar o encriptarlas.

The design of the identity service, P_IDENT, does not allow programs to ever come in direct contact with the user's cryptographic key pair, nor to inject information into currently-open sessions which are using the identity service for signing or encryption.

Varios

Además de las protecciones ya mencionadas que contemplan distintas partes del modelo de riesgos, los permisos P_RTC y P_THEFT se combinan para ofrecer un sistema anti-robo que requiere de un grado de sofisticación importante (manipulación del hardware) para ser eliminado, y el P_DSP_BG provee una protección contra ciertos tipos de malware impertinentes, tales como el infame virus Yankee Doodle de 1989.

In addition to the protections listed above which each address some part of the threat model, permissions P_RTC and P_THEFT combine to offer an anti-theft system that requires non-trivial sophistication (ability to tamper with on-board hardware) to defeat, and P_DSP_BG provides protection against certain types of annoying malware, such as the infamous 1989 Yankee Doodle virus.

Faltantes a la lista

Por lo menos dos problemas, comúnmente asociados con laptops y chicos como usuarios de computadoras respectivamente, no son discutidos en nuestro modelo de riesgo o sistemas de protección: la encriptación del disco rígido y el filtrado / control parental de contenido cuestionable.

At least two problems, commonly associated with laptops and child computer users respectively, are not discussed by our threat model or protection systems: hard drive encryption and objectionable content filtering / parental controls.

Encriptación del sistema de archivos

Si bien las laptops XO no poseen un disco rígido técnicamente hablando, la pregunta sobre la encriptación de datos es perfectamente aplicable al almacenamiento primario de memoria flash. La respuesta consiste de dos partes: primero, la encriptación del sistema de archivos sería demasiado lenta para nuestro hardware. Las laptops XO pueden encriptar 2-4MiB/s usando el algoritmo AES-128 en modo CBC, usando 100% de la CPU. Esto es aproximadamente 1/10 de la velocidad de transferencia del chip flash NAND. Cambiando a un algoritmo más rápido como el RC4 permitiría aumentar la velocidad de encriptación a unos 15MiB/s usando bloques grandes y una utilización del 100% de la CPU, y por lo tanto sigue siendo demasiado lento para un uso generalizado, y provee una seguridad cuestionable. En segundo lugar, dada la edad de nuestros usuarios, hemos diseñado la plataforma Bitfrost explícitamente para que no requiera del usuario el uso de palabras claves para controlar el acceso a su computadora. Pero sin palabras claves, la encriptación de datos del usuario tendría que recaer sobre identificadores únicos de la laptop misma, lo cual no brindaría ninguna protección a los datos en el caso de ser robada.

Una vez que la plataforma Bitfrost soporte la protección P_PASSWORD, posiblemente no antes de la segunda generación de laptops XO, proveeremos el soporte para que el usuario encripte archivos individuales si es que la protección es activada y configurada con una palabra clave por el usuario.

While the XO laptops have no hard drive to speak of, the data encryption question applies just as well to our flash primary storage. The answer consists of two parts: firstly, filesystem encryption is too slow given our hardware. The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC mode, using 100% of the available CPU power. This is about ten times less than the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4 increases encryption throughput to about 15 MB/s with large blocks at 100% CPU utilization, and is hence still too slow for general use, and provides questionable security. Secondly, because of the age of our users, we have explicitly designed the Bitfrost platform not to rely on the user setting passwords to control access to her computer. But without passwords, user data encryption would have to be keyed based on unique identifiers of the laptop itself, which lends no protection to the user's documents in case the laptop is stolen.

Once the Bitfrost platform supports the P_PASSWORD protection, which might not be until the second generation of the XO laptops, we will provide support for the user to individually encrypt files if she enabled the protection and set a password for herself.

Filtrado de contenido cuestionable

La plataforma Bitfrost es el gobernante del sistema de seguridad de las laptops XO. Dado que el término "contenido cuestionable" carece de toda definición técnica, siendo algo puramente social, el filtrado de dicho contenido cae fuera de los alcances de la plataforma de seguridad y este documento.

The Bitfrost platform governs system security on the XO laptops. Given that "objectionable content" lacks any kind of technical definition, and is instead a purely social construct, filtering such content lies wholly outside of the scope of the security platform and this document.

Descarte de la laptop y seguridad de transferencia

El tiempo de vida pensado para una laptop XO es de cinco años. Una vez transcurrido dicho tiempo, el propietario de la laptop puede querer deshacerse de ella. De modo similar, y por razones logísticas, una laptop puede cambiar de manos, de un dueño a otro.

Un programa de re-inicialización de la laptop será provisto para borrar de manera segura la identidad digital del usuario y todos sus documentos de la laptop. De ser ejecutado en modo "descarte", el programa también podría deshabilitar permanentemente a la laptop, aunque no esta muy claro que dicha funcionalidad sea de hecho necesaria, y por lo tanto no hay planes para proveerla.

The target lifetime of an XO laptop is five years. After this time elapses, the laptop's owner might wish to dispose of the laptop. Similarly, for logistical reasons, a laptop may change hands, going from one owner to another.

A laptop re-initialization program will be provided which securely erases the user's digital identity and all user documents from a laptop. When running in "disposal" mode, that program could also be made to permanently disable the laptop, but it is unclear whether such functionality is actually necessary, so there are no current plans for providing it.

Comentarios finales

En la mitología Nórdica, Bifröst es el puente que impide a los mortales, habitantes de Midgard, aventurarse en Asgard, el dominio de los dioses. De hecho, Bifröst es un poderosos sistema de seguridad diseñdo para mantener alejados a intrusos no deseados.

Esta no es la razón detrás del porque el nombre de la plataforma de seguridad de la OLPC es un juego sobre el mítico puente. Lo que es particularmente interesante de Bifröst es una historia que el historiador y poeta islandés Snorri Sturlson del siglo XII cuenta en su manual poético llamado Edda prosaica. He aquí un extracto relevante:

In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of the realm of Midgard, from venturing into Asgard, the realm of the gods. In effect, Bifröst is a powerful security system designed to keep out unwanted intruders.

This is not why the OLPC security platform's name is a play on the name of the mythical bridge, however. What's particularly interesting about Bifröst is a story that 12th century Icelandic historian and poet Snorri Sturluson tells in the first part of his poetics manual called the Prose Edda. Here is the relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:

Nota: esta es una traducción ad-hoc al castellano de la traducción al inglés por Arthur Gilchrist Brodeur de 1916.

Y entonces Gangleri dijo: "Cual es el camino al cielo desde a la tierra?"
Y entonces Hárr contestó, riéndose: "Vaya, no es preguntado de manera sabia; acaso no se le ha dicho, que los dioses han hecho un puente desde la tierra, al cielo, llamado Bifröst? Seguramente lo habrá visto; podría ser que lo conozca como arcoiris. Es de tres colores, y muy fuerte, hecho con ingenio y más artes mágicas que otros trabajos de manufactura. Pero fuerte como es, debe aún ser roto, cuando los hijos de Múspell avancen cargando y lo atraviesen, y naden con sus caballos sobre los grandes ríos; así será."
Y entonces Gangleri dijo: "A mi parecer los dioses no construyeron el puente honestamente, sabiendo que puede ser roto, y siendo capaces de hacerlo como quisieran."
Y entonces Hárr respondió: "Los dioses no merecen ser recriminados por este trabajo habilidoso, un buen puente es Bifröst, pero nada en este mundo es de naturaleza tal de ser confiado cuando los hijos de Múspell cargan."

Then said Gangleri: "What is the way to heaven from earth?"

Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has it not been told thee, that the gods made a bridge from earth, to heaven, called Bifröst? Thou must have seen it; it may be that ye call it rainbow.' It is of three colors, and very strong, and made with cunning and with more magic art than other works of craftsmanship. But strong as it is, yet must it be broken, when the sons of Múspell shall go forth harrying and ride it, and swim their horses over great rivers; thus they shall proceed."

Then said Gangleri: "To my thinking the gods did not build the bridge honestly, seeing that it could be broken, and they able to make it as they would."

Then Hárr replied: "The gods are not deserving of reproof because of this work of skill: a good bridge is Bifröst, but nothing in this world is of such nature that it may be relied on when the sons of Múspell go a-harrying."

Esta historia es notable, ya que en suma es el reconocimiento que desde el siglo XIII existe la idea de que no existe un sistema de seguridad perfecto.

Usando los terminos de Sturluson, creemos haber imbuído al sistema de seguridad de la OLPC con ingenio y más artes mágicas que otros trabajos de manufactura—pero ni por un segundo creemos que hemos diseñado algo que no pueda ser roto cuando talentosos, determinados e ingeniosos atacantes carguen. De hecho, esa no era la meta. La meta era elevar significativamente la barrera del actual y profundamente insatisfactorio estado de la seguridad del escritorio (desktop). Creemos que Bitfrost cumple con ello, aunque solamente cuando las laptops esten en el campo seremos capaces de determinar con algún grado de certitud si lo hemos logrado.

Si el tema les interesa, por favor unanse a la lista de seguridad de la OLPC, comparta sus ideas, y unase al debate.

FIN

This story is quite remarkable, as it amounts to a 13th century recognition of the idea that there's no such thing as a perfect security system.

To borrow Sturluson's terms, we believe we've imbued the OLPC security system with cunning and more magic art than other similar works of craftmanship -- but not for a second do we believe we've designed something that cannot be broken when talented, determined and resourceful attackers go forth harrying. Indeed, this was not the goal. The goal was to significantly raise the bar from the current, deeply unsatisfactory, state of desktop security. We believe Bitfrost accomplishes this, though only once the laptops are deployed in the field will we be able to tell with some degree of certainty whether we have succeeded.

If the subject matter interests you, please join the OLPC security mailing list, share your thoughts, and join the discussion.


END

Créditos

Autor

Ivan Krstić
ivan EN laptop.org
One Laptop Per Child
http://laptop.org
   5 :Author
   6     Ivan Krstić
   7     ivan AT laptop.org
   8     One Laptop Per Child
   9     http://laptop.org

Agradecimientos

Simson Garfinkel, un consultor de seguridad para la OLPC, contribuyó a este documento. Este documento también se basa sobre un área en crecimiento conocido como "HCI-SEC", el campo de recientes avances de la Interacción Humano Computadora con el importante objetivo de la seguridad informática. Para más informacion sobre HCI-SEC referirse a "Security and Usability", por Lorrie Cranor y Simson Garfinkel (O'Reilly, 2005), y en la tésis PhD de Garfinkel, "Design Principles and Patterns for Computer Systems that are Simultaneously Secure and Usable" (MIT, 2005).

Reconocemos también al panel de reviewers que prefieren permanecer anónimos, y que proveyeron comentarios y observaciones valiosos sobre las versiones previas de este documento.
  11 :Acknowledgments
  12     Simson Garfinkel, a security consultant for OLPC, contributed to this
  13     document.  This document also builds upon a growing body known as
  14     "HCI-SEC," the application of recent advances in the field of Human
  15     Computer Interaction to the important goals of computer security. More
  16     information about HCI-SEC can be found in the book "Security and
  17     Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in
  18     Garfinkel's PhD thesis, "Design Principles and Patterns for Computer
  19     Systems that are Simultaneously Secure and Usable" (MIT, 2005).
  20 
  21     We acknowledge also a panel of reviewers that prefer to stay anonymous, who
  22     provided insightful comments and feedback on previous drafts of this
  23     document.

Metadata

Revisión: Borrador-19 - distribución 1
Fecha y hora: Wed Feb 7 00:50:57 UTC 2007
URL comentarios: http://mailman.laptop.org/mailman/listinfo/security
Versión de referencia para este documento: http://wiki.laptop.org/go/Bitfrost
Todo comentario sobre este documento será bienvenido, preferentemente en la lista pública de la OLPC sobre seguridad, a la cual se pueden suscribir por medio del URL ya mencionado. Si prefiere mantener sus comentarios privados, puede enviar un email al autor de este documento a su dirección arriba mencionada.
Esta versión de la especificación NO es la definitiva. Sus contenidos reflejan exactamente el pensamiento de la OLPC en materia de seguridad al momento de ser redactado, pero ciertos aspectos del modelo de seguridad pueden cambiar antes de la producción. Este documento será actualizado para reflejar dichos cambios. La versión más reciente se puede encontrar en el URL de referencia.
  25 :Metadata
  26     Revision: Draft-19 - release 1
  27     Timestamp: Wed Feb  7 00:50:57 UTC 2007
  28     Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
  29     Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost
  30 
  31     We welcome feedback on this document, preferably to the public OLPC
  32     security mailing list, for which you can sign up at the feedback URL given
  33     above. If you strongly prefer to keep your comments private, you may mail
  34     the author of the document at the provided e-mail address.
  35 
  36     This is NOT the final version of the specification. The contents of this
  37     document accurately reflect OLPC's thinking about security at the time of
  38     writing, but certain aspects of the security model may change before
  39     production. This document will be updated to reflect any such changes. The
  40     latest version of this document may be found at the authoritative version
  41     URL.