Slashdot Log In
One Laptop Per Child Security Spec Released
Posted by
ScuttleMonkey
on Wed Feb 07, 2007 06:41 PM
from the no-school-like-the-old-school dept.
from the no-school-like-the-old-school dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
But what about DCOM in my ActiveX? (Score:5, Funny)
I'm thinking it would work well to implement such a feature so that the writing widget can talk to the chat widget and the spreadsheet widget. I was planning on calling it, Dynamic Communication Over Methods, or DCOM for short.
Now I'm bummed!
It's worse than that, it prevents app partitioning (Score:5, Insightful)
Actually, it's even worse than your funny (but accurate) comment suggests:
In the Unix model, applications are often built out of multiple cooperating processes, each of which is isolated into its own address space, with strong barriers between processes enforced by the MMU hardware. This makes each separate part more robust, more comprehensible, and more secure.
In contrast, when Bitfrost throws away the ability of programs to talk to other programs, it is intrinsically encouraging a monolithic approach to program design, which is a huge step backwards both for security and for complexity management.
Bitfrost is right to deny free access by programs to a user's filestore objects as an important part of its new security framework, but if the price for that is to disallow strong application factoring and partitioning into separate but communicating processes then the cure may be worse than the disease.
Parent
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.
Parent
RTFA - this is not DRM or Trusted Computing (Score:5, Informative)
If you RTFA, they specifically designed the security model so that children could write their own apps which can do *anything*. But they set up some defaults (which can be overridden) to protect the system.
What they are aiming at is a way to set sensible limits per-program, at install time: So at install time, a package (they call it a bundle IIRC) has a list of specific rights that the program will need in order to do its job. If the bundle doesn't ask for a certain right at install time and tries to use it later (because, say, it was maliciously modified), it will be denied.
If an app *is* signed by OLPC, it can have any right that it specifically asks for at install time. Otherwise, there are some rules about what subsets of rights are allowable together (i.e. asking for certain rights will exclude certain others by default). But again, the whole thing can be overridden.
This is nothing like Trusted Computing or DRM. It's more like a wrapper around SELinux (I don't know if that's actually how they implemented it).
Parent
Yes, better security... (Score:5, Funny)
Drastic? (Score:4, Insightful)
Drastic?
I'd be willing to work toward "acceptable" or "workable".
The problem with "drastic" is that it often envisions high frontier technologies when all that is needed is a really well thought out plan.
If the UNIX system worked well for nearly 40 years, and was fairly simple to implement, then another 40 years *might* be had with something equally simple.
Re:Drastic? (Score:4, Insightful)
Parent
Re:Drastic? (Score:4, Funny)
Parent
Sand dunes (Score:4, Insightful)
The article talks about the picture-viewer not being able to access the web. What if I *want* the picture-viewer to access the web ?
I tihnk I take issue with 99% of applications not needing interaction. If that's true (and I doubt it to be honest), I think that's a failing of software today, not a goal to be strived for. Most of the apps I use daily require web/internet access. I think that's only going to increase over time.
Simon
Re:Sand dunes (Score:5, Informative)
The document said that it was not possible for the application to request P_DOCUMENT_RO access and network access simultaneously during installation.
But it also said that it was perfectly OK for a user to go in and explicitly grant P_NET access via the GUI to an application with P_DOCUMENT_RO access, thereby giving you an application that is able to read your images and mass upload them to teh interweb, but only to those users who know enough to explicitly use the security interface.
Also the OLPC or local government could issue a signed XO package that offered that functionality to younger children.
Parent
very sceptical (Score:5, Insightful)
So anyone coming up with a "new and improved" security concept is selling an untested solution. Because security is always tested in the field, never (at least never properly) in the lab.
And yes, Unix permissions are primitive. But they work, they are reliable and we know their shortcomings and limitations.
Re:very sceptical (Score:5, Insightful)
True, but inapplicable in this case. For two reasons.
How can we have a new security model, but no new security model concepts? What's new is that ideas which have been reserved for high-security systems are being applied to a system that large numbers of people will actually use.
The core ideas are:
The only innovation here is in the decision to apply these known security models/tools to all applications on the OLPC. There is some good thought that has gone into determining what kinds of restrictions can be placed on apps, and the bit about constraining the permissions that apps can request during installation (e.g. either network or file access, not both -- without digital signature or explicit user authorization) is clever, but there's nothing fundamentally new.
But the issue is somewhat deeper than that, as well.
It's important to realize that the traditional security model does not work for OLPC machines. Why? Because (1) they're specifically designed as computers whose software is highly mutable and (2) they're specifically designed to live as part of a network. The traditional model works great if you can thoroughly prove the integrity of the software on the system and then lock it down -- but you can't do that on machines that are constantly connected to others and always exchanging bits of code and data.
You can try, of course. And we do. And we've seen just how well it works. Massive botnets of zombies is the result as is high-powered machines dedicating a significant portion of their processing power to defending themselves against malicious code -- and failing.
The traditional model is fundamentally broken in the networked age, and the OLPC machines are not only networked, but designed to facilitate every user becoming an at least minimally-competent programmer and to encourage widespread, free sharing of user-developed code.
New problems require new solutions. In this case, it appears that we already had all of the tools required available, they just weren't widely used.
My prediction: The XO security model will be an outstanding success story. It'll have its problems, and it'll have to be tweaked in various ways, but the basic ideas are so good, and so fundamentally simple, that it will work very well. Application authors will be able to achieve what they want, and security will be generally quite good.
I also think that the OLPC project is one of the most amazing stories in the history of computing. It's giving a bunch of brilliant people the opportunity to completely re-imagine computing, and they're doing it with a laser focus on the needs of the people who use the computers, rather than the needs of those who sell the computers and the software.
Parent
The one major difference to MS "trusted" computing (Score:5, Insightful)
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."
That is the one of the key differences between Bitfrost and Microsoft
"trusted computing" schemes: you as owner of the box can get around it.
It's not hard to do this. Just not compatible. (Score:5, Insightful)
It's not hard to do this. Several groups had systems this tight working back in the 1980s. For that matter, Multics had it right in the late 1960s. Linux has it now, in NSA SELinux.
It breaks existing applications, of course. The OLPC people have a huge advantage - they don't care about existing applications. They can say to application developers, "these are the security constraints - design to them." That's a huge win.
Somebody should have done this by now for phones and palmtops, but, unfortunately, those things started out so underpowered they barely had an operating system. So they have their own legacy problems.
Re:It's not hard to do this. Just not compatible. (Score:4, Informative)
Parent
Two Cents (Score:4, Insightful)
I've got two things to say.
1. Bring these security additions to public linux distributions.
2. Would you (and the rest of
Re:$5000 laptop? Pulleeze!! (Score:5, Informative)
Hardcore geek != executive.
You've obviously never met an executive, they don't have the slightest problem splashing out (from the company account) well upwards of $5000. They think they're worth it.
Parent
Re:More Power to Em (Score:4, Informative)
Plus it's only a matter of time before the first solitaire clone ships with a "request everything available (and not conflicting with their simple limits model)" setting, because the app dev was too lazy to tie things down.
If you want a glance at that, install SELinux in non-enforcing mode and look at the log. You'll be surprised what kinds of system calls and file accesses your simple applications make that they don't really need. Much of that is just routine init stuff from some library they use, and most fails silently and with no trouble if they can't get that port or file lock they request, but still...
Parent
Re:chmod, chown, etc.? (Score:5, Insightful)
Well, Windows uses the ACL system of permissions it stole from VMS. It actually does provide more control (that you don't need 99.9% of the time), such as multiple groups having different levels of permissions.
Increasingly complex file-level security does come with one major drawback, however... I can look at a file under Linux and instantly tell (possibly with a quick check of the members of a single group) who has what access to it. Under Windows, good luck with that. XP actually has an advanced security tab, "Effective Permissions", solely for the purpose of testing what access a given user has to a file or directory. Short of that tool, some of the more complex possible configurations (which don't take any sort of unrealistically contrived setups to get, such as a combination of local and domain groups having both inherited and locally set permissions) would leave you feeling very uncomfortable guessing who has access to a given file. And of course, that tab only lets you check one user or group at a time, so it proves utterly useless in answering the simple question "Who can overwrite this file".
In fairness, you could write a script to test every user and group against a given set of files and directories and generate a report off the output, but seriously, would anyone really consider that "better" than "0750, yup, that looks good"?
Parent
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".
Parent
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.
Parent
Re:One Desktop per Village would be a better start (Score:5, Insightful)
Parent
Re:One Desktop per Village would be a better start (Score:4, Insightful)
Parent
Origin/rationale for name (Score:5, Interesting)
Parent
Linux did clone the Plan 9 feature though (Score:5, Insightful)
When you want a new namespace, you specify the CLONE_NEWNS flag. (root only, sorry, because of setuid concerns)
Once you have a new namespace, you can unmount things you don't need. You can do bind mounts, which let you graft directories onto other places. You can use a bind mount to make a read-only copy of something, then unmount the original... all without mucking up processes that aren't part of the same CLONE_NEWNS group. Portions of the filesystem tree can be shared as well, in case you really do want changes to appear to both sides of the CLONE_NEWNS. Access to things can be permanently given up within the CLONE_NEWNS group, making for a rather fine jail that generally beats jail(8) quite severely.
There are extra goodies for stuff like isolating the view of system time, the view of executing processes, etc.
Parent