eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I have to admit upfront that Ive never been enamored of the One Laptop Per Child project. I think computers are way down the list of assistance needed in the countries targeted by this program. Still, some very smart people have put a lot of sincere, hard work into it, and its always interesting to see a whole new architecture planned.
Im not sure how much actual work has been done so far on security, but a lot of design specifying has been. The “Bitfrost” specification (click here for a short summary) by Ivan Krstić, is the main document describing the security philosophy and strategy for the OLPC. Its a great read and not really all that long.
The key philosophy is one that is not especially controversial these days, especially when dealing with children: “… we will ship and enable by default a stringent policy thats 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.“
eWEEK test-drove the $100 laptops interface.
Click here
to see what it looks like.
Even Windows attempts to do this to a degree, although systems like Windows and OS X are burdened, compared with OLPC, with an installed base and existing applications. They have to take such things into account when creating new security restrictions. But what OLPC creates is a new base set of rules for all development, although of course a lot of existing Linux code will be moved over to OLPC in short order.
OLPC may want to restrict users by default, but it also wants to encourage them to work beyond the restrictions: “… 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.” As a necessary precaution for such users, it goes on to describe (in very vague terms) a system for system recovery and data backup.
It seems to me that the scenarios described by Krstić place a great burden on what Ill call, for lack of a better term, IT support for the schools in which these PCs will reside. The plans also have insufficient provision for social engineering attacks.
A good part of Bitfrost is devoted to a scheme to combat theft and tampering that resembles—and this is really ironic—Windows Product Activation. Its not about copy protection, but the similarities are out there in the open. Each system has a unique identifier flashed into it, and the distribution system will keep track of which system codes were shipped through authorities in each country receiving the system. The systems are not usable until they are activated through a local activation server set up by (probably) the school. When the notebooks are turned on, they look on Wi-Fi for the activation server, or they can be activated manually via the keyboard.
For some countries, the authority in charge of distributing the OLPCs generates a list of activation codes for the notebook batches for each school, and the codes are put on a USB drive. At the school this drive is plugged into a server provided by OLPC. They can also use any other computer running the right software, including an OLPC, which then becomes the activation server. Theres a lot more to activation. Its also involved with the generation of each childs “digital identity,” which is used for authentication.
Back to privilege-based security, the model depends on applications to define the privileges needed and to stick to those requested privileges. When an application attempts to perform an action not permitted by its initially requested permissions, it fails. Bitfrost is also adamant that it fail simply, saying, in effect, “No, you cant do that.” They reject the Vista model of allowing a one-time permission fix. Instead, if exceptions must be made, they send users to the oft vaguely mentioned “graphical interface,” which seems to be a permissions administration program.
This is a perfectly good model, as far as it goes. The Bitfrost spec shows the authors Unix-ish bias for simple programs that do simple things: They give the example of Windows Solitaire, which has no need to read and write files. And yet, under Windows it has the ability to do whatever the logged-in user can do (Windows is actually capable of process-level privileges, but its an underused facility). So the idea for OLPC is that if a program asks to do something for which it has permission, this may be because it has become compromised, through an overflow perhaps, and the operation should be denied.
Next page: When programs get complicated.
When Programs Get Complicated
My problem with this is that once programs get complicated, as they often do outside of the Unix command line, tracking all these privileges gets complicated. Users want their programs to do useful things like send e-mails and save to a flash drive. Expecting the “IT support” at the school to decide how to handle errors is not a reasonable thing to do. There are other complicated decisions, such as default numbers for rate limitation on network access, that are left to some authority I dont assume will be present.
Bitfrost doesnt specifically address the issue, but I think it expects a lot of someone at the school administering systems. As we know from the sad story of Julie Amero, who was prosecuted because her class PC had become infected with a porn popup-spamming program, even in the filthy-rich United States of America school IT may not get the job done on security.
Check out eWEEK.coms for the latest news, views and analysis of technologys impact on government and politics.
And the basic issue of social engineering is not specifically addressed, except to the extent that technical measures in Bitfrost may prevent operations the user may be prompted to do by an attacker through a social engineering attack. But Im sure that still leaves some leeway for dangerous operations, and the possibility that the permissions administrator can be fooled into allowing the installation of a dangerous program. Its really not that hard to envision a school of OLPC notebooks becoming infested with bots, if a resourceful attacker tried to get them in there.
And there are people at OLPC who envision such attacks. If enough of the notebooks are out there, they automatically become a target just because of their numbers. The standard configuration and relative naiveté of the user base make them more tempting targets. Other people at OLPC recommend that the activation and central backup projects be postponed, if necessary, in order to get more effective prevention in place against social engineering attacks.
As highly as I value education, including computer education, I think there are better ways to aid the desperately poor parts of the world than to send them cheap computers. I think OLPC will fail because even such countries will see their money better spent in other ways. But I wouldnt be surprised to see some useful experimentation coming out of the project. Even if Im right about mistakes made the first time around, I suspect theyre not afraid to learn from them and fix them, and thats an effort worth supporting.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers blog Cheap Hack
More from Larry Seltzer