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.'"
jail is a hack (Score:3, Informative)
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.
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.
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...
Re:chmod, chown, etc.? (Score:2, Informative)
Re:Sand dunes (Score:1, Informative)
Of course, if the picture viewer has no ability to access the web (has no web features say) then it doesn't request that feature from the OS at install time, and thereafter if it is ever compromised (e.g., buffer overrun in the JPEG decoder), it still cannot access the web.
I think this forces developers to think about interprogram interaction and design good protocols for it instead of just ad hoc flinging data around.
Re:I'd rather hope not... they'll use it for DRM. (Score:2, Informative)
Re:Even worse (Score:2, Informative)
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.
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.
Re:chmod, chown, etc.? (Score:3, Informative)
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?
Re:chmod, chown, etc.? (Score:3, Informative)
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.
Re:It's not hard to do this. Just not compatible. (Score:4, Informative)
Re:Even worse (Score:3, Informative)
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.
Re:It's not hard to do this. Just not compatible. (Score:4, Informative)
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).
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.
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 permissions as well, but the key security tools defined by Bifrost are MAC, not RBAC.
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).
Where does it say that? (Score:4, Informative)
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.
Re:Try right-clicking 1000 files.... (Score:3, Informative)