One Laptop Per Child Security Spec Released 253
juwiley writes "The One Laptop Per Child project has released information about its advanced security platform called Bitfrost. Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Vista? 'What's deeply troubling — almost unbelievable — about [Unix style permissions] is that they've remained virtually the only real control mechanism that a user has over her personal documents today...In 1971, this might have been acceptable...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.'"
Even worse (Score:2, Interesting)
Netware was also better in this respect whilst it was still in mainstream use, despite being more of a runtime system than a real OS.
A Stink-Rose by any other name... (Score:3, Interesting)
"Beyond cyberthreats, the XO laptop will have an anti-theft system designed to render stolen laptops useless. Each XO is assigned a "lease," secured by cryptography, that allows it to operate for a limited period of time. The laptop connects to the internet daily and checks in with a country-specific server to see if it's been reported stolen. If not, the lease is extended another few weeks."
Congratulations, you have destroyed this projects credibility, desirability and much of the good will that the open source community was providing.
I wonder this would rule out any interaction with the GPL v3?
Re:chmod, chown, etc.? (Score:4, Interesting)
I think the traditional UNIX model is too simple to call bolting on an List of names and permissions used for Access Control (in place of the user/group/mask approach) a "trivial tweak".
It isn't about ACLs. (Score:5, Interesting)
It's the sandboxing. A program run by a given user doesn't automatically get the user's full permissions -- it only gets a small subset. For example, it can't open files from the user's home directory other than by calling a trusted system File Open dialog, which allows the user to select the file and returns an open file handle to the application (or in OLPC's case hardlinks the file into the chroot jail).
In terms of research projects, see the secure scripting language E [erights.org] and the proof of concept CapDesk [combex.com].
Interestingly, in the commercial world it only seems to turn up in safe bytecode runtimes -- there's very little out there for native code. For an example of something similar in concept look at JNLP [sun.com] or ClickOnce [microsoft.com] deployers.
Takes Big Brother to the next level (Score:2, Interesting)
"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."
Remember kids, file sharing is illegal and there is a database full of mugshots for the RIAA to find you.
Origin/rationale for name (Score:5, Interesting)
Re:One Treacherous computer per Child (Score:5, Interesting)
If you'll RTFA (yeah, I know, no one does that...), the system can be completely disabled if the user so wishes. The purpose of the PKI is not to force someone to only use certain software; it's to help ensure that security updates haven't been compromised before getting to the laptop.
As for installing another Linux distribution, would that even be possible at present? I doubt any other distro would run properly on the OLPC's custom hardware without extensive modifications. Sure, you can argue "but they should have the freedom to break it if they want" -- and they do, as the article says. All this stuff can be disabled. Overwriting the OS should disable the anti-theft daemon, since the anti-theft system is implemented entirely in software.
I think the anti-theft provisions that turn the laptop into a brick are a bit much, but the actual spec (which I'm sure you didn't read either, as you're misquoting it) notes that the lease period can be set to any value (chosen by the country manager who distributes the laptop). A lease period of 3 months is given as an example. And in extreme circumstances, a USB drive with credentials that can be used to extend the lease period without needing access to the internet.
At any rate, the spec mentions that the anti-theft system is only installed and enabled on the request of the country purchasing the laptops. So it's not like the OLPC group is forcing this on anyone. If the countries are spending the cash on these things, I think it's reasonable that they should be able to try to protect their investment.
I have a decent number of reservations about the entire OLPC program, but c'mon, at least don't make up shit about it that isn't true.
Sigh. Hidden DRM plan. (Score:2, Interesting)
FTFA:
Beyond cyberthreats, the XO laptop will have an anti-theft system designed to render stolen laptops useless. Each XO is assigned a "lease," secured by cryptography, that allows it to operate for a limited period of time. The laptop connects to the internet daily and checks in with a country-specific server to see if it's been reported stolen. If not, the lease is extended another few weeks.
If the lease expires, the XO's internet connectivity is turned off, and shortly thereafter the whole computer becomes a brick. In the case of an area without internet connectivity, a local school can extend the lease from its own server by Wi-Fi or with a USB dongle.
I've been hearing that they were going to do this for a while, and I think it's a terrible idea that will kill a lot of the potential of this wonderful project. What happens if these kids go to another area for a month or two and want to take the thing with them? Tough, it's a brick. Not to mention if they want to keep it and take it out of area after they graduate.
There's also this deeply worrying gem:
Users can manually assign more power to a particular program through the security control panel, but even there, they are limited.
"You cannot request a set of permissions that let you do bad things," Krstic said.
So much for a computer that students will have complete control over, can take everything apart and put it back together, etc. For a project so focussed on empowering kids as users, these two parts of an otherwise promising security plan sound an awful lot like the computer having control over the user, not the other way around.
I hope I've got this wrong, I hope that we aren't actually introducing third world kids to the world of DRM and Treacherous Computing, where "their" machines do things they can't control, where they "lease", not own. If so, it's really too bad. Yet another missed opportunity...
Re:chmod, chown, etc.? (Score:3, Interesting)
Yes, actually, I do. And I'd say most of the same complaints about VMS - Except that Windows doesn't have the rock-solid stability to make up for the hellishness of use.
Yeah, because right-clicking a file or folder, selecting Properties, then choosing the confusingly labeled Security tab is difficult.
Hypothetical situation for you...
You have Domain Admin (but not EA) on a standard mid-sized multi-site corporate network. A finance-related folder on your NAS has users, local groups, domain groups, and forest groups set on it, including possibly-contradictory local and inherited permissions.
Quick, in 15 seconds or less, tell me who in the Dallas Accounting office has write permission to the 2006 internal audit folder.
You can fairly plead that you couldn't even have such a situation under Linux (not with the stock FS permission system, anyway), but I would say the same thing in support of my stance.
Re:chmod, chown, etc.? (Score:3, Interesting)
Who holds the keys? (Score:3, Interesting)
The people who hold these keys are plenty vulnerable to corruption, intimidation and good old-fashioned trickery. This doesn't invalidate the security model, but I'd be interested to know how they mean to preserve the integrity of the keychain in case of theft, misuse, disaster, going-out-of-business and aliens.
L
uh, FYI, Linux DOES have ACLs now (Score:3, Interesting)
The ACLs are usually almost like the ones Windows uses, with a few minor differences:
a. UNIX-like systems normally still use rwx.
b. Windows normally disables checking permissions on parent directories.
c. Windows does a funny sort of inheritance thing that kills performance. (thus the above speed hack)
The stuff OLPC is using is way more powerful though. An ACL on your own data file will not protect your data from being damaged by a trojan. The OLPC project uses mandatory access control (mostly a domain-type-role enforcement mechanism) to stop such problems.
Re:Even worse (Score:3, Interesting)
Symlinks don't have permissions of their own, they inherit the permissions of whatever they link to.
What apps? I've never run into an app that requires root when it shouldn't. Not even various commercial software makes that mistake.
What distros? No distro I can think of (Gentoo, Fedora, (K)ubuntu, Suse, Debian, ...) assumes that root will be the regular user.
not a new security system (Score:3, Interesting)
A few years back, the NSA wrote an implementation of this for Linux. It's called SE Linux. It's a bit modernized, supporting more than just the old military-style security levels.
Linux also has CLONE_NEWNS, which is based on features from an old research OS called Plan 9. That, combined with some neat tricks involving mount points, gives you something like chroot() with extra power.
Most of the code has been around for years. OLPC just integrated it nicely into the app installer and made the user experience tolerable.