Slashdot Mirror
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.'"
If my OLPC applications are completely isolated, how am I going to implement this new idea I have for cross-application communication based on shared pipes among apps.
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!
The Kai's Semi-Updated Website Thingy
So, I bet that my cell phone has better security than a $5000 vista laptop, but you can do stuff on that laptop that you can't on my phone. (not sure what, but i'm sure there's something porn related)
Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
"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.
"Rocky Rococo, at your cervix!"
At the moment every other OS has better security than Windows, what's new?
http://plan9.bell-labs.com/magic/man2html/2/fork
RFCNAMEG If set, the new process starts with a clean name space. A new name space must be built from a mount of an open file descriptor.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
I'll meet you at the intersection of "Should be" and "Reality"
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
Physicists get Hadrons!
What executive, or any human being do you know is using a $5000 laptop? Even the most hardcore geeks I know spend only up to about $2k for the best laptops.
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.
There are shills on slashdot. Apparently, I'm one of them.
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.
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.
Assorted stuff I do sometimes: Lemuria.org
--"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.
From TFA
"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?
Loop, twist and loop again.
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. 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.
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.
Deleted
Silicone is for tits. Silicon is for computers.
Linux has had IRIX-style ACLs and POSIX ACLs for quite a long time: The the "chacl" and "setfacl" commands. This has
been in all the popular distributions of Linux since forever. Unix permissions started out with just the RWX model, but
ACLs were added a *long* time ago to mainstream Unixen, and Linux followed shortly after. The problem with ACL systems is
that they're generally too complicated to manage by mere mortals, and they're a pain to maintain. That's true whether you're
talking Winderz, Unix, Linux, Multics, whatever.
Further, the "sandboxing" model is nothing new. SELinux has facilities for doing this--quite ornate facilities, in fact.
Formulating apprropriate "sandboxing" policy for every application is even more of a pain than ACLs. In fact, there's
still a whole lot of "grad school fever" about automated methods for determining "correct" policy for systems like
SELinux, both based on a formal description of programs behaviour, and runtime analysis. It ain't easy.
SELinux has been standard in Linux kernels for about 1 (or is it two?) years. Many of the distributions, including
Fedora, include the high-level support tools for SELinux.
Once you do that, it isn't the traditional Unix model anymore -- it's something more like POSIX ACLs, which Linux *does* support, and which *does* provide the ability to give one group write while another has read.
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".
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?
Every time you post an article on Slashdot, I kill a server. Think of the servers!
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 and the proof of concept CapDesk.
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 or ClickOnce deployers.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
"Manufacturing data includes two unique identifiers: SN, the serial number, and U#, the randomly-generated UUID."
"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.
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?
I've got two things to say.
1. Bring these security additions to public linux distributions.
2. Would you (and the rest of
\
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.
>> 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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.
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:
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!
CUR ALLOC 20195.....5804M
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.
"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."
You do realize Microsoft hired Dave Cutler (the guy who created VMS) to design NT, right? I wouldn't say they stole VMS, Cutler simply applied his knowledge of ACL security to Windows NT security.
"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."
Yeah, because right-clicking a file or folder, selecting Properties, then choosing the confusingly labeled Security tab is difficult. I can see how people become confused, especially those leet UNIX hackers. If you are just looking, then you're a friggin' idiot if you can't figure security in Vista or XP. If you're adjusting security then you need to do a little reading first, but learning how to use an OS, regardless of which one it is, rerquires a little effort. If you're an leet UNIX hacker, how hard can this be, right?
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.
This is not entirely true: A file chmod'd 777 appears to be readable and writeable by everyone, but if it's contained within a directory chmod'd 700, then it is accessible to only the owner (unless a user has an open handle to that directory already, but let's not split hairs). Ditto if the parent directory is 777, but *that* directory's parent is 700.
The same is going on with Windows permissions, albeit in a more complicated fashion: the permissions set on parent directories are (or, more accurately, can be) inherited by the children. Admittedly, in Windows, since there are more permissions to inherit, things are somewhat more complicated.
Are you just trolling?
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.
Xfce: Lighter than some, heavier than others. Just right.
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...
No jokes, please
For multiple users changing permissions or multiple owners, read man setfacl
I just did, it contains this line:
o Exactly one user entry specified for the file
owner.
You have have the owner be a group, which would allow multiple users to technically be the owner, but this is not the same thing as having multiple owner permissions on the file.
Hardlinks by the way, make the standard unix permissions system much more useful,
You're right, I don't understand this. Hardlinks are an aid to data organization (and more importantly, data redundancy, which is much less of a problem than it used to be), not security. The only advantage hardlinks have over symlinks that that certain utilties treat symlinks different from filesa nd you might not want that behavior. Sure you can use lots of hardlinks and symlinks to minimize the amount of directories you have to permission, but then you have to maintain all the symlinks and hardlinks and make sure THEY have the proper permissions. I don't understand how this reduces work or really adds much capability.
And while I'm at it, I'd point out that ACLs are a mess on Linux because only a fraction of the software supports ACLs. For example, Konqueror strips ACL information off files it moves. I can think of 4 apps on my little Linux box that REQUIRE that they be run as root, etc. You might complain that I shouldn't use that software, but I've found the the MAJORITY of software for Linux either doesn't properly support ACLs and/or needs to run as root. In fact, the assumption that root will be running almost everything seems to be built into Linux and most of the Linux distributions I've used.
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) 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.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
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.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
This $5000 laptop that came preloaded with Windows Vista, still isn't as secure as those $100 laptops used by poor third world children.
You do realize Microsoft hired Dave Cutler (the guy who created VMS) to design NT, right?
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.
There's another major drawback you missed. Managing permissions on NT systems is quite a pain. It often takes more work, and more repeating yourself to get what you want. This means that there's a higher chance that people will make a mistake when setting permissions. Also people are more likely to leave files with inappropriate permissions because they are too lazy to go to the work of doing it right.
As with any sufficiently strong security system, the weakest link I foresee will be the people. In this case, not the people who *use* the XO, but the people who control various points along the keychain: developer keys, activation keys, etc.
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
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).
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.
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.
Basically all UNIX-like systems support ACLs now.
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.
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.
Game! - Where the stick is mightier than the sword!
The concept, called mandatory access control, goes back decades. It comes from the US military. It was originally based on the classified info system (SECRET, TOP SECRET, etc.) and was intended to stop insiders causing leaks. Insiders tend to make dumb security mistakes, and sometimes even sell secrets to the enemy. Mandatory access control stops that cold.
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.
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.
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.
"when Bitfrost throws away the ability of programs to talk to other programs"
I read the whole article but I don't remember reading that anywhere.
I read some stuff about programs not being able to look at other program's files, but that's not the same thing at all.
I'm pretty sure OLPC uses IP, and that means sockets. If you've got sockets then you've got inter-process communication.
Unless you've got proof that OLPC doesn't have named pipes, etc. then I suspect you're pulling misinformation out of somwhere the sun don't shine.
No sig today...
Ctrl-A, Properties. Voila, set properties for all the 1000 files at once.
xkcd is not in the sudoers file. This incident will be reported.