Security: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
m (Reverted edits by 200.89.84.90 (Talk) to last revision by Quozl) |
||
| (34 intermediate revisions by 12 users not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == |
|||
Security needs to be a guiding principle of the entire OLPC design. Without a security model that is workable, implementable, and usable, the child's laptop will quickly become an unusable laptop. |
|||
There are many ways that children involved in the OLPC effort might fail to benefit from their involvement. Some of these educational failures stem from security threats such as laptop theft, software interference, or socially malicious pranks. Therefore, we have created a [[Security#Threat Model|threat model]], a number of [[Security#Design|designs]], and several [[Security#Design|implementations]] that we think will help mitigate these threats. More information about these artifacts can be gleaned from other [[:Category:Security|pages on security]]. |
|||
While the danger in creating a "Security" page is that it can become a ghetto for security discussions, there are specific ares that can best be discussed in pages created specifically for this purpose. Each of these issues is given a specific page for the discussion of security policy and implement ation. |
|||
Unfortunately, providing truly dependable software is a '''challenging''' task at best. Fortunately, there are many ways that you can help out, both [[Developers|generically]] or [[Security#Contributions|particularly]]. Finally, if you are interested in speaking with [[Security credits#Active Contributors|security people]], know that they are readily available. |
|||
==Security Goals and Principles== |
|||
== Threat Model == |
|||
* '''Usable security.''' The security mechanisms need to be easy to understand and easy to use. Ideally, secure operation should emerge organically and naturally through the laptop's normal operation. The user shouldn't have to be forced to decide between doing something in a manner that is secure and a manner that is expedient. |
|||
* '''Visibility.''' Security state and configuration should be evident. It should be clear when a given operation changes or somehow compromises the security of the system. |
|||
* '''Reversibility.''' It should be relatively apparent how to reverse configuration changes and restore security settings. |
|||
* '''Least Surprise.''' "The system should match the user’s experience, expectations, and mental models. In the context of computer security, this principle means that the computer should not perform an action in a manner that is not secure when the user expects the computer to be behaving in a secure manner. For example, if the user fills out a form on a web page that was fetched with SSL (and therefore has a lock in the browser’s status bar), the browser should warn if the form’s POST operation causes the data to be sent without encryption to another web server. (Ideally, the browser would even warn the user of this possibility before the user had invested time in filling out the web form.) Likewise, if the user instructs the computer to delete a file and the file disappears from the computer’s list of files, then the file should actually be deleted." |
|||
* '''Good Security Now.''' We can't build a system that offers perfect security, so we're going to try to build a system that offers good security now. |
|||
* '''Standardized Security Policies (no kit)''' Provide a small number of standardized security configurations that can be audited, documented, and taught to users. |
|||
* '''Consistent and Meaningful Vocabulary''' Prevent confusion by using words consistently to convey the same idea or concept in different programs and contexts. Likewise, prevent confusion by assigning consistent meanings to the same word in different applications or contexts. |
|||
* '''No External Burden''' Design security systems to have minimal or no negative impact on the friends, associates and co-workers of those using the technology, so that they do not push back on the users of the tools and ask that the use be curtailed. |
|||
The threat model for the OLPC XO running Sugar is discussed in the [[Bitfrost]] summary and in the [[OLPC Bitfrost|full specification]]. |
|||
(Quotes above are taken from [http://www.simson.net/thesis/]) |
|||
NB: The ''authoritative'' version of this document is [http://dev.laptop.org/git/security/tree/bitfrost.txt bitfrost.txt]. |
|||
==Security Technologies== |
|||
[[Complete Delete]] |
|||
[[Digital Signatures]] |
|||
== Design == |
|||
All software running on the XO could compromise the security goals of the XO users; however, only some of this software has been considered in light of the user's security goals and the Bitfrost threat model. |
|||
=Related Pages= |
|||
[[Privacy]] |
|||
Some programs, classes of programs, and features that have received particular scrutiny include: |
|||
; Activities |
|||
: [[Rainbow]] deals with implementation and design of the activity isolation model suggested by Bitfrost. |
|||
; [[Open Firmware]] |
|||
: [[Firmware security]] and [[Early boot]] discuss how we address the security considerations of the firmware-OS level. |
|||
; [[Theft-deterrence protocol|Theft deterrence]] |
|||
: [[User:Mstone/Commentaries/Security_1]] examines the security requirements of the ''first-boot activation'', ''passive-kill'', and ''active-kill'' features. Elsewhere, the impact of [http://lists.laptop.org/pipermail/security/2008-June/000441.html signature delegation] on theft-deterrence goals and security is analyzed. |
|||
; Software update |
|||
: [[Software update]], [[Olpc-update]], [[OFW NAND FLASH Updater]], [[Nandblaster_for_XO-1]], [[Nandblaster_for_XO-1.5]] and others are programs for getting new software onto an XO. |
|||
: [[User:Mstone/Commentaries/Mass olpc-update]] discusses the interactions of [[olpc-update]] and the [[theft deterrence protocol]]. |
|||
== Contributions == |
|||
You can contribute to the education received by hundreds of thousands of children this year by: |
|||
; writing software |
|||
: Review the documentation cited above, then bring your questions and patches to the [mailto://security@lists.laptop.org security mailing list] ([http://lists.laptop.org/listinfo/security subscribe]). |
|||
; refining the threat model and mitigation strategies |
|||
: Did we miss an important threat (e.g. to privacy)? If so, please work with us to fix our model. |
|||
: Alternately, if you have expertise in a related field like sociology (''what notion of identity should our software reify?'') or criminology (''the who/what/where/why/how of stolen laptops''), please improve our theories and recommended practices. |
|||
; breaking assumptions |
|||
: Software 'security' is proven under fire. Here's your opportunity to crank up the heat. |
|||
; organizing other people |
|||
: Many people are capable of improving the security of their software but for the lack of some critical resource like knowledge, motivation, or criticism. Find and provide the missing piece. |
|||
; spreading the word |
|||
: Many of our ideas on software security are transferable to other operating systems and environments -- particularly to other Unix-like machines. Help port our ideas or software to another platform so that others can benefit from them and can help us improve them on their own terms. |
|||
== Procedures == |
|||
Some day soon, we'll try to write up some simple procedures to ease the task of making the security contributions described above. Ping the [mailto://security@lists.laptop.org security list] ([http://lists.laptop.org/listinfo/security subscribe]) if you want this up. |
|||
== Thanks == |
|||
Many people, both named and anonymous have contributed to the security of software available on the XO and hence to the quality and power of the education received by hundreds of thousands of kids this year. If you or your organization would like to be recognized for your contributions, please add your name and affiliation to the [[Security credits]] page along with a brief description of what you worked on. |
|||
[[category:security]] |
|||
[[Category:Subsystems]] |
|||
Latest revision as of 14:02, 8 October 2010
Introduction
There are many ways that children involved in the OLPC effort might fail to benefit from their involvement. Some of these educational failures stem from security threats such as laptop theft, software interference, or socially malicious pranks. Therefore, we have created a threat model, a number of designs, and several implementations that we think will help mitigate these threats. More information about these artifacts can be gleaned from other pages on security.
Unfortunately, providing truly dependable software is a challenging task at best. Fortunately, there are many ways that you can help out, both generically or particularly. Finally, if you are interested in speaking with security people, know that they are readily available.
Threat Model
The threat model for the OLPC XO running Sugar is discussed in the Bitfrost summary and in the full specification.
NB: The authoritative version of this document is bitfrost.txt.
Design
All software running on the XO could compromise the security goals of the XO users; however, only some of this software has been considered in light of the user's security goals and the Bitfrost threat model.
Some programs, classes of programs, and features that have received particular scrutiny include:
- Activities
- Rainbow deals with implementation and design of the activity isolation model suggested by Bitfrost.
- Open Firmware
- Firmware security and Early boot discuss how we address the security considerations of the firmware-OS level.
- Theft deterrence
- User:Mstone/Commentaries/Security_1 examines the security requirements of the first-boot activation, passive-kill, and active-kill features. Elsewhere, the impact of signature delegation on theft-deterrence goals and security is analyzed.
- Software update
- Software update, Olpc-update, OFW NAND FLASH Updater, Nandblaster_for_XO-1, Nandblaster_for_XO-1.5 and others are programs for getting new software onto an XO.
- User:Mstone/Commentaries/Mass olpc-update discusses the interactions of olpc-update and the theft deterrence protocol.
Contributions
You can contribute to the education received by hundreds of thousands of children this year by:
- writing software
- Review the documentation cited above, then bring your questions and patches to the security mailing list (subscribe).
- refining the threat model and mitigation strategies
- Did we miss an important threat (e.g. to privacy)? If so, please work with us to fix our model.
- Alternately, if you have expertise in a related field like sociology (what notion of identity should our software reify?) or criminology (the who/what/where/why/how of stolen laptops), please improve our theories and recommended practices.
- breaking assumptions
- Software 'security' is proven under fire. Here's your opportunity to crank up the heat.
- organizing other people
- Many people are capable of improving the security of their software but for the lack of some critical resource like knowledge, motivation, or criticism. Find and provide the missing piece.
- spreading the word
- Many of our ideas on software security are transferable to other operating systems and environments -- particularly to other Unix-like machines. Help port our ideas or software to another platform so that others can benefit from them and can help us improve them on their own terms.
Procedures
Some day soon, we'll try to write up some simple procedures to ease the task of making the security contributions described above. Ping the security list (subscribe) if you want this up.
Thanks
Many people, both named and anonymous have contributed to the security of software available on the XO and hence to the quality and power of the education received by hundreds of thousands of kids this year. If you or your organization would like to be recognized for your contributions, please add your name and affiliation to the Security credits page along with a brief description of what you worked on.