One Laptop Per Child Security Spec Released

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.'"

Drastic?

[geomon]

"drastically more secure and provides drastically more usable security"

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.

Promising if they manage to follow through

[Lifyre]

This would indeed be a nice step forward in security if they manage to complete all their principles and goals. It would be nice to have a system that I can hand out to users (or famliy members) that is basically secure out of the box but with a little reading and changing of settings I can obtain full control over. The idea that it would be open is certainly a nice boost to credibility and would, if successful, push all security forward and not just their own.

Sand dunes

[Space cowboy]

The idea of putting every application into a virtual machine is a good one, but the truism is that security *is* a process, not a checkbox on a feature-list. There is (and always will be) an inverse relationship between security and usability - the more of one, the less of the other. Compartmentalising the applications in such a draconian fashion would appear to be heavily leaning towards the security side, and not the usability side of the argument.

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

More Power to Em

[99BottlesOfBeerInMyF]

This really is a good idea and hopefully others will follow suit. Applications simply are not all trustworthy and the assumption that they are is a huge failing of most modern OS's. I hope they get this right. There are a lot of pieces here no one has perfected. They need restrictions, proper services between applications and to them, granular levels of trust, or ACL profiles, means of easily and accurately assigning those trust levels, and a well crafted UI for programs that want to override their trust level. Best of luck to them.

Re:Drastic?

[kabocox]

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.

Nah, we'd need something drastic to fix what we currently have. Linux/Unix wouldn't help if it became dominate and users gave out root passwords to every program that asked nicely for them. I've just read the intro, and this sounds like it would be awesome if it works. I'm taking await and see outlook for the entire project. When the project gets to the point where slashdot could buy 1 million of these and all slashdotters bought several $100 laptops for each family member then we'd find out the limits of this system. I'd like to see if my mom could play her AOL flash games on this thing without tons of spyware getting installed in the process. Until this system is rolled out and being used, we just don't know if it is better, worse, or about the same as our current security models. I'd wait 4-5 years after its been rolled out to a few million kids to see if hackers have owned the entire system or if it runs as they said it should. The hackers could always break into the system the way that a legimate program from the cert. authority would. What happens when poorly written AOL flash games or spyware is certified from the government purchaser or a hacker uses the gov. cert. keys to run on those computers?

very sceptical

[Tom]

Security is a lot like crypto: Designing your own system is a recipe for desaster. Security is hard, and aside from the conceptual stages, small failures in implementation can destroy the best concept.

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.

The one major difference to MS "trusted" computing

[gd23ka]

--"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."

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.

Re:Drastic?

[Harmonious Botch]

I'll offer my 'well thought out plan': Real security only happens when there is a button ( with a missle-launch-type cover ) on the side of my computer, so that some tracks of disk and some banks of memory cannot be written to unless that button is pushed.

Re:chmod, chown, etc.?

[pla]

I wonder if the author's used chmod, chown, etc.? What's the essential difference between Unix style permissions and other permission systems?

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"?

It's not hard to do this. Just not compatible.

[Animats]

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:Drastic?

[4e617474]

I just had to su change the permissions on a config file so I could change the settings on vegastrike to steer with the mouse. With your model (yes, I detected the humor) developers would design around the "they can just hit the button" principle, even when they are writing things to "just work" remotely. Security will happen when people learn:

1. This is a computer. You need to know how it works and what you're doing as you use it. Alternatively, you can wash dishes for a living and go outside and play when nothing is on TV.
2. Some people are your friends and give you a bunch of stuff for nothing. Some people are not your friends, but pretend to be.
3. Even your friends do not need to borrow your identity.

Windows ACL permissions are nice

[Colin Smith]

Pity they're so badly set by default. Unix could do with allowing groups within groups. It would allow admins to add group permissions to a resource and then add user groups to the resource group. Its sort of possible using NIS, but then you're stuck with NIS. The simplicity of Unix permissions is handy, but you can have that same simplicity using Windows just by managing the acls properly.

Still, the fact that Unix permissions are still around, being used and adequate for most people is a testament to the concept.
 

Re:Even worse

[imemyself]

One of the problems that I have had with Unix permissions is that - irregardless of ACL's - RWX is not enough for file servers. Being able to choose more specifically what a user can do (for example, Windows supports things like create files, create folders, take ownership, change permissions, etc). The biggest problem I have is that there is no way to change ownership of files if you're not root. Same thing with changing permissions, if you're not the owner. There are also some instances where I do not want the owner to be able to change permissions. Windows and Netware/OES make it relatively easy to specify more granular permissions. While some of this may be possible on Linux, I doubt it would be as easy or quick to use as it would be on Windows/Novell.

Now, I admit that it can be a pain to do stuff from the command line on Windows, however, that hopefully will get a bit better with PowerShell.

Now SELinux might change some of that, but from my very limited experiences, it is (or atleast was a year and a half ago) a PITA to deal with. That being said, I'm sure its improved since I've tried it. However, isn't it more for limiting what a program can do (who it can talk to, network access, etc), than file permissions?

Re:One Desktop per Village would be a better start

[Goaway]

I can't help but notice that the people working on this "too ambitious" project are actually out there doing it, while you are... posting on Slashdot?

Two Cents

[kahrytan]

I've got two things to say.

1. Bring these security additions to public linux distributions.

2. Would you (and the rest of /.ers) be willing to purchase 1 of these laptops for $200? I say $200 so the extra $100 goes toward a laptop for a child in third world country.

Re:One Desktop per Village would be a better start

[dbIII]

Forget about the theft angle - the surpisingly large rate of mobile phone adoption in the third world shows valuble bits of easily stolen electronics are not all going to suddenly get sold back to westerners. These things are infrastructure and I see them as comparable to the Australian School of the Air run by radio to remote areas since the 1920s. The concept of the possibilites of such a thing is explored in fiction in "The Diamond Age" - connected to the net these things are books with a lot of answers.

Re:Yes, better security...

[supabeast!]

On top of the functionality issue, there's also the time and skill of the users to consider. People who can afford high-end laptops can usually deal with reformatting the hard disk and grabbing documents from a network share, the last thing poor children need to do is stop their lives to reformat their laptops.

It's worse than that, it prevents app partitioning

[Morgaine]

>> how am I going to implement this new idea I have for cross-application communication based on shared pipes among apps.

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.

It's just the usual Trusted Computing fallacy

[patchvonbraun]

One could reasonably posit that at some point, you're going to want to use the OLPC to teach children
    computer programming.

That means that in order to execute any such programs on their OLPC, those programs are going to need to be
    "signed" by an "authority" before they can be executed. That gets old fairly quickly, so an alternative
    obvious policy is that any program that was compiled on *this* OLPC is "safe" for this OLPC. Right.

The problem with Trusted Computing world views is that computers are simply *appliances*, with some 3rd party
    in control of what this "appliance" can do. The end result is that rather than having a *truly* computer-literate
    population, we instead perpetuate the elite software priesthood. Imagine a world where only the "priesthood"
    are granted programming licenses, with technology like Trusted Computing (and this OLPC stuff) used to
    "enforce" such licensing schemes.

There are lots and lots and lots of situations where non-programmers have reasonable need to write programs
    from time to time. Think scientists writing simulations, engineers, artists, etc, etc. The minute you
    actually grant your "appliance" Turing Completeness, you've lost its Trusted Computing properties.

I see this as an unresolvable dicotomy.

"What's deeply troubling..."

[rnturn]

"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..."

Oh, my! I feel so... so... exposed!

So let's make the default umask "077" for all UNIX- and Linux-based systems. Would that help? To a great extent. Would it decrease usability? Sure. But if that 'swhat it takes to have some semblance of system security, so be it. It seems that work on file-level security has taken steps backwards since the "do everything via a browser" mentality began taking root in UNIX/Linux. That us brings automatic execution of programs based on some file's extension (the so-called "helper" applications). Yep, that proved to be such a winner in the DOS/Windows arena that we should all start doing it. What little cool feature of the web that makes something easier to do hasn't proven to have gaping security holes in it? Every so-called "advance" in usability seems to have a detrimental effect on system security. Always has and, I'd bet, always will. Usabililty and security are playing a zero-sum game. You can't seem to have more of one without less of the other. But I digress...

I don't know what the ultimate solution will be but I'm thinking that liberal use of "umask 077", RBAC (especially on root) and ACLs, and a default policy of "drop" on one's firewalls will go a long way in protecting system(s). All of those have been available on UNIX/Linux for quite a while. So much for permission bits being "virtually the only real control mechanism that a user has over her personal documents today".

The creator of this "BitFrost" cryptographic security scheme says:

"I fear there is something I missed."

Frankly, I kept having the same feeling as I read the Wired article. I think what it was that he was missing was "simplicity". Dongles for laptops in rural villages? Local license servers for villages that have no internet access? Jeebus!

Re:Umm, how's this gonna work?

[adisakp]

The OLPC poject gave up on existing software years ago. All OLPC applications must be written (or ported) specifically for OLPC.

128 MB RAM and 512 MB total storage in Flash RAM.

Of course all the apps are specifically rewritten for OLPC. Security aside, most applications written for today's computers with 100+GB HD's won't load on a computer with only 128 MB of RAM without VM. Heck, with swap-files/VM disabled, you can't boot into a typical install of XP if you only have 128MB RAM much less run any applications.

Sigh, then again, I remember when my Amiga had a useful pre-emptive multitasking OS running multiple GUI programs in only 512K (that's K not M) and my storage being 880K floppies. Of course, since there was no security, one program could crash the machine so I do envy Bitfrost. I think these OLPC's will have plenty of power and memory for poor kids as long as they can avoid bloatware and cruft.

There are things in the spec I object to...

[LuckyStarr]

Wow, I read the whole FA. I must be new here.

Seriously, I agree with most their findings and strategies to mitigate the risks of theft, lost privacy, etc. I also find it noteworthy that the Mic and Cam both have a direct wired LED to indicate activation of said components, where the LED can not be turned on/off by software at all. Thus eavesdropping becomes evident. The spec is a nice read and most points Ivan makes are (from my standpoint) well thought through and sensible for the environment in which the XO is to be deployed.

What I object against though, is point 8.12 (P_X) [laptop.org] of the spec. As I understand it, as long as you happen to be in possession of a "trusted" key to the machine (which will certainly be OLPC and the government of the child in posession of the XO) you may eavesdrop on any resource of the X window system as you see fit? Correct me if I am wrong, but AFAIK the X protocol was never designed with security in mind. So sending commands to another program might also impicitly mean the ability to check the state of that program.

Would any X expert please confirm or dismiss this, as I can't becase I'm no X expert myself.

Re:chmod, chown, etc.?

[Michael Woodhams]

Yeah, because right-clicking a file or folder, selecting Properties, then choosing the confusingly labeled Security tab is difficult.

Too right it was difficult. My WinXP installation decided that a "security" tab was just too confusing so it didn't display it. There was some arcane ritual I needed to perform to enable it. The help files mostly just assumed this ritual had been performed, so they said "click on the security tab and then...", flatly contradicting what I could see (a Properties window with no security tab). There was a lot of frustration before I stumbled on the ritual.

Hey Microsoft

[Disharmony2012]

This $5000 laptop that came preloaded with Windows Vista, still isn't as secure as those $100 laptops used by poor third world children.

Re:A Stink-Rose by any other name...

[kelnos]

Also from TFA:

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.

So, it's not enabled by default. I'm not a huge fan of this system, but higher up in the spec where it's described, it appears to be implemented entirely in software (it's a *deterrent*, not intended to make it completely theft-proof). So enterprising kids could potentially mod the kernel to allow them to kill the anti-theft daemon.

The situation isn't quite so dire, either. The lease periods can be set to any arbitrary value (the spec uses 3 months as an example of a longer period). Would you really expect the machine to not hit the internet for 3 months, even in a poor country where connectivity is spotty? Even then, the leases can be extended without internet access using a special USB key that can be provided to the schools with the laptops.

Regardless, if the OLPC country managers want to shell out the cash for these, and are worried about theft, why shouldn't they be allowed to request a way to protect their investment? $100 comes pretty close to the GDP in a lot of third-world countries (and possibly even exceeds it in some places).

Re:very sceptical

[swillden]

So anyone coming up with a "new and improved" security concept is selling an untested solution.

True, but inapplicable in this case. For two reasons.

1. There are no new concepts in the XO security model.
2. The traditional security model (used by Unix and Windows) cannot work for the OLPC, so something different is required.

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:

• Sandboxing, aka Mandatory Access Controls. Not only have research systems built on this concept existed for years, but we also have a decade of practical experience with Java sandboxes, and several years of extensive experience with MAC on Linux (SELinux). Specialized high-security operating systems have employed MAC for decades.
• Chroot jails. Most sysadmins who are serious about security run all Internet-facing applications in jails, to limit the damage that can be done if the app is exploited. The only difference here is that the concept is being applied to all apps.
• Digital signatures as a way to authorize applications to break out of their constrained (sandboxed and jailed) environments.
• Allowing users to authorize applications to break out of their constrained environments.
• Security by default. The system is secure out of the box.

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.

RTFA

[r00t]

Programming is allowed. There is even a "view source" button on the keyboard!

Sharing programs (binary executables) with your friends is easy and encouraged. All programs are severely sandboxed by default, so there is no problem unless the attacker finds a bug in the CPU hardware. The sandboxing is really well thought out; an app bundle (install package) can request camera access or net access but not both. Apps never get more permissions than they requested at install time, excepting when an advanced child modifies the permissions.

Linux has a few features that make this possible. The first is of course SE Linux policy, which could be adjusted by the app installer. The second is CLONE_NEWNS with bind mounts, allowing app-specific views of the filesystem that simply lack any unneeded files.

The only mildly troublesome restriction is that kernel and firmware modifications require that the child request a laptop-specific developer key from OLPC. There is a 14-day waiting period intended to allow time for laptop theft to be reported; you can't get a developer key for a stolen laptop.

Linux did clone the Plan 9 feature though

[r00t]

Our rfork() is called clone(), or unshare() if you don't need a new thread/process.

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.

Re:It's not hard to do this. Just not compatible.

[fwr]

First, the two concepts "virtual machine" and "mandatory access control" are orthogonal. A virtual machine may choose to implement MAC (and the sandbox that Java applets are placed in is a MAC implementation), or it may choose any other security model (or none).

Hence my difficulty in classifying the type of access control. I don't know enough about the Java sandbox to say whether it is MAC or not, but I doubt it. MAC entails assigning a specific classification to each object, and clearances to subjects, and then comparing the clearance of the subject with the classification of the object. There are also different security models such as Bell-LaPadula, Biba, and Clark-Wilson, that have to do with subjects accessing objects of different security levels. If the Java sandbox implements only allowing a subject (the Java app) access to particular objects I suppose you could stretch the definition of MAC to fit that model, but MAC connotates a much more complex system that is usually only seen in military systems (or special implementations of Unix such as Trusted Solaris and SELinux).

Mandatory Access Control is simply a set of permissions that are independent of the identity of the user who owns a process. Unix and Windows permissions are all about the process UID, every decision about what the process should or should not be allowed to do comes down to a check of user-related information.
With MAC, the permissions are associated instead with the process and/or the data it's acting on. MAC as implemented by SELinux (and the XO security model, BTW) associates a set of permissions with each program. Program A is configured as being allowed to do X or Y but not Z, while program B is allowed to do Y or Z but not X.

This is an oversimplification. Any access control system can be described as "simply" checking permissions for a subject against permissions for an object. It's the relation between the two that makes the difference. For example, DAC systems check the identity of the subject against the ACL (list of access specified by the owner of the object) of the object. RBAC systems check the identity of the subject against the access rights assigned to the object by the owner or administrator. As opposed to DAC systems RBAC systems are generally focused on assigning access rights to objects based upon the subjects membership in a group that has a particular role, as opposed to assigning rights to a specific individual subject. MAC systems, as indicated earlier, are quite different in that the compare the classification of the object with the clearance of the subject. MAC systems also have the concept of "need to know" so that a subject with a particular clearance level, for instance someone with top secret clearance, does not necessarily get to access all top secret objects (and shouldn't!). So it's an oversimplification because all access control systems by definition have to compare the level of access granted to a subject for an object. These different models of access control don't necessarily match the specific implementations available in systems today. However, they do form a basis for comparing different means of access control.

Note that these permissions are orthogonal to UID-based permissions. Suppose a program has permission to read files from a given region of the file system, but the user account the program is running as does not have permission to read a given file within that region. The program can't read that file while running as that user.
Second, there's nothing in the Bifrost spec about virtual machines. It's not clear, but it looks to me like the Bifrost MAC is implemented at the OS layer, in spite of the fact that the Wired article talks about VMs.
No, it is most definitely not role-based -- role-based access is again based on user ID (via the roles associated with that UID at the moment). Actually, I think there are probably traditional user and group-based

I don't think so

[Wesley Felter]

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

But a program and a process are not the same thing. If an OLPC app is structured as several processes, then they will all run in the same jail and will all be able to communicate with each other.

Also, it's not correct to say that Bitfrost doesn't allow programs to communicate at all. Obviously programs communicate with the X server. And the document mentions D-BUS, so programs are probably allowed to communicate that way.

It's clearly SE Linux plus CLONE_NEWNS

[r00t]

Bitfrost isn't one single technology. It's the integration of several existing Linux technologies with a nice GUI, installer, set of keys, etc.

The neat jailing feature has been in Linux for years, though mostly unused. You can access it via either the clone() or unshare() system call. In combination with bind mounts and PID namespaces, you get the ability to jail quite effectively. To learn more:

man 2 clone
man 2 unshare
man 8 mount

SE Linux is of course the other major underlying ability, and then there's the new GUI and app installer to tie it all together in a usable way.