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

Comments

But what about DCOM in my ActiveX?

[filesiteguy]

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!

Re:But what about DCOM in my ActiveX?

[Original Replica]

Please call it: Dynamic Methods Communication Application

Re:But what about DCOM in my ActiveX?

[nuzak]

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

When unix actually makes reasonable use of pipes, let me know. You can pass open file descriptors over a pipe. This makes it possible for a security process to open an otherwise inaccessible file on its behalf and hand it back to you without requiring any funky "security descriptors". The fd can itself be a pipe -- think on that one for a few moments.

Some people build robots out of legos, but we're still building boring flat walls out of the ones that unix gives us.

Re:But what about DCOM in my ActiveX?

[nixkuroi]

You should call it Dynamic Method Affected Communication or "D'MAC". You could ship it with a pimp hat on the config screen and then make sure all the applications that you write with it can be hammered through a backdoor.

It would be functionally the same as DCOM but much, much cooler.

Re:But what about DCOM in my ActiveX?

[Hal_Porter]

> You can pass open file descriptors over a pipe.

But they won't be any use at the other side of the pipe, since they are per process. If you pass one across a process boundary, it won't mean anything.

Re:But what about DCOM in my ActiveX?

[nuzak]

They work across processes just fine when they're duplicated by the kernel -- such as with fork, or by passing them across a unix socket (sorry, not a pipe ... sure would be nice though). SCGI (a fastcgi workalike) for example does the fd-passing-over-socket trick in its reference implementation.

If you want to try this trick out yourself, try Paul Jarc's fdtools -- the 'sendfd' app demonstrates its use http://code.dogmap.org/fdtools/

Plan 9 naturally does make heavy use of this trick, and has a sendfd syscall specifically for it. It's been ported to Linux too, part of Plan 9 From User Space.

So everything is in a jail(8)...

[dextromulous]

I don't know if this is a good idea or an awesome idea.

Re:So everything is in a jail(8)...

[TheSHAD0W]

Whichever it is, it's definitely DRASTIC.

chmod, chown, etc.?

[xxxJonBoyxxx]

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

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

there's a drawback to his system: It limits interactions between applications.

It would be nice if we knew if this means copy/paste is broken. (I'm thinking not, but I've been wrong before.)

Re:chmod, chown, etc.?

[abigor]

"What's the essential difference between Unix style permissions and other permission systems?"

ACLs.

Re:chmod, chown, etc.?

[AuMatar]

An ACL is a group of people allowed to use a file. Its a different way of implementing the same thing, you can convert an ACL to a Unix group by ccreating a group and adding everyone you would add to the ACL to the group. Its just changing where the overhead is- per file overhead of an ACL and the high overhead of ACL checking on access, or a high number of groups in the OS, overhead to the user of group creation, and low run time overhead of checking group membership.

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

Re:chmod, chown, etc.?

[Anonymous Coward]

You definition of ACL is a little weak and misses the true capabilities that a rich ACL system provides. ...or said another way you could map Unix file permissions into file related ACLs but you cannot always map ACLs into Unix permissions.

Re:chmod, chown, etc.?

[Anonymous Coward]

Mind you, you can't always. For example, in Unix you can't give one group of people read access to a file and another group write access.

Re:chmod, chown, etc.?

[AuMatar]

You could with a trivial tweak to the Unix model. I'm surprised someone hasn't done that to Linux yet.

Re:chmod, chown, etc.?

[dbIII]

What's the essential difference between Unix style permissions and other permission systems?

There are people that propose shortcuts so users don't have to use chmod or chown in any form and can arbitrarily create new defacto groups. Some of these people have some good ideas, others consider the group controls too restrictive and requiring specific people to set things up and others just don't understand the concept of allowing groups of users to access files at all. Large organisations often need tight restictions but have time contraints on anyone who has the permission to set up groups and medium sized ones can have security policies lax enough to have financial database admin passwords written on bits of paper attached to monitors so they don't get this user/group/all permissions thing.

There's also stuff like preventing access to directories after 5PM which I see mainly as a reason to phone sysadmins at 3AM just waiting to happen. Personally I haven't yet hit a situation where I need more than the unix permissions and really see security problems with the concept of an inexperienced temp employee creating and dissolving defacto groups but other situations have other problems.

Re:chmod, chown, etc.?

[cduffy]

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

Re:chmod, chown, etc.?

[Goaway]

I wonder if the author's used chmod, chown, etc.?

Obviously not. You are so much smarter than them.

Re:chmod, chown, etc.?

[value_added]

Well, Windows uses the ACL system of permissions ... does provide more control (that you don't need 99.9% of the time)

I'd add that "not needed" is often synonymous with "never used".

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.

That's the key. Unix file permissions are straightforward, standard, and in your face at all times. Granted, Windows has a philosophy of dumbing things down, or obscuring things to give give the user an appearance of simplicity, but past that, ACLs aren't very manageable by users or administrators without undue effort, time, and knowledge. Put another way, the Windows Explorer interface (or any registry tool) doesn't display permission information (requiring the use of tools like xcacls, etc., or rummaging through numerous dialog boxes, instead), and even if it could, few could make sense of it, let alone put it to good use.

Re:chmod, chown, etc.?

[oggiejnr]

On a Windows XP Pro machine, the Explorer properties dialog will display all of the permissions providing Simple File Sharing is turned off

Re:chmod, chown, etc.?

[Anonymous Coward]

Riiight.

Security setups are only as complicated as you make them. So I doubt you'll run into such cases very often (unless you're using deny permissions which makes everything more complicated).

Last week I saw a very simple and realistic setup on a directory tree. Developers can read and write (two). Users (the two people who can program the machine accessed with this system) can read and execute the code. Nobody else can touch it. How do you handle that with just an owner-group-all system?

I can right away tell who can write. Just look through the permission list and see that developers_XYZ are the only ones with write access, and get the list of users from that group.

Re:chmod, chown, etc.?

[stubear]

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

Re:chmod, chown, etc.?

[zollman]

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.

Re:chmod, chown, etc.?

[gad_zuki!]

Welcome to slashdot, you will most likely be moded down as an uninformative troll for even suggesting right-click > properties.

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.

Re:chmod, chown, etc.?

[griffjon]

I was a bit confused by:

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

Uh, actually, the computers with UNIX-like security permissions are doing pretty well. It's that pesky one that abandoned it that gets all the virii and malware...

Re:chmod, chown, etc.?

[pla]

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.

Re:chmod, chown, etc.?

[a.d.trick]

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.

Re:chmod, chown, etc.?

[pla]

So I doubt you'll run into such cases very often (unless you're using deny permissions which makes everything more complicated).

So... ACLs don't get complicated... unless... we use the complicated features thereof?

"Riiight"



Developers can read and write (two). Users (the two people who can program the machine accessed with this system) can read and execute the code. Nobody else can touch it. How do you handle that with just an owner-group-all system?

"chown -R whoever:developers devpath"
"chmod -R g+rw,o-rwx devpath"
"chown -R whoever:users usepath"
"chmod -R g-w,g+r,o-rwx usepath" (you probably wouldn't want to force g+x, but could)
"make install" (copies the resulting executables from devpath to usepath).

Re:chmod, chown, etc.?

[mollymoo]

That's feasible for the code example, where you actually do move files around as part of the normal process. But what if it's a bunch of images or documents? It's no longer part of the process, it's a workaround. Documents which should be read together should be kept together - whether or not everybody gets to read everything or edit everything. With vanilla *nix permissions, you need version control and publishing mechanisms to do that. They're naturally part of the software development process (because your errors might stop someone else doing their thing), but not naturally part of every other process where multiple files are used my multiple people.

Re:chmod, chown, etc.?

[Lehk228]

so it proves utterly useless in answering the simple question "Who can overwrite this file".

it's windows, the answer is probably "that shifty looking guy in the parking lot with a cantenna on his dashboard"

Re:chmod, chown, etc.?

[cmacb]

"It's no longer part of the process, it's a workaround."

Note: I'm not a sys-admin for Unix or Windows, but I've certainly been in Windows environments where the ACL and rights set-up was so complex that nobody (particularly the sys-admins) understood it. I'd bet it isn't all that uncommon for an overworked sysadmin to just find a trusted user in the group that's having problems and just give them all powers over a particular area so that they (the sysadmin) don't get called so often.

I think simplicity in a security system has it's advantages, even if it requires a few workarounds. Those can be well documented, use single owner executables etc. or as you said use some sort of version control (which exists as applications for photos, CRM, or other database driven systems). Which brings me to another gripe I have with many Windows systems, which is the tendency to rely on the file system to do too much, like a single folder with hundreds of thousands of photos in it. Try bringing that up in file manager while files are still being added. Why did they do it this way? Because they didn't know any better and figured that anything they could do on a small scale on the desktop should just work fine in a server environment with orders of magnitude larger load.

Too many organizations are allowing Windows servers to be administer and used as though they are just beefed up PCs, and they mistakenly think they can get kids right out of high school with some certification under their belt to run them... I digress.

Re:chmod, chown, etc.?

[iamacat]

Make developers members of both developer and user groups and have them chgrp files when done then. Or do a loopback, read only mount of development directory to some location to which users have permissions. If you run out of options, ask yourself if massive concurrent access to the files that requires such permissions is really safe in terms of users overwriting each other changes or completely corrupting your documents or images.

Re:chmod, chown, etc.?

[thsths]

> My WinXP installation decided that a "security" tab was just too confusing so it didn't display it.

That is a deliberate restriction in Windows XP Home. In the specs it says that XP Home does not support ACLs. But of course the kernel does support ACLs, only the GUI refuses to deal with them. But they are still there, which can make life an absolute pain if you try to set up a LUA.

"Broken by design" are the words to come to my mind here...

Re:chmod, chown, etc.?

[Magada]

You don't work much with documents, do you? Any sort of editing that involves more than two people is automatically in need of version control and publishing mechanisms - and this is as true for source code as it is for tomorrow's newspaper.

Re:chmod, chown, etc.?

[YU Nicks NE Way]

You have domain admin rights, but not enterprise admin rights? Unless you're in Dallas, you can't and shouldn't be able to tell who has access to the folder.

Re:chmod, chown, etc.?

[mollymoo]

Not as much as with code, no. But where I have (specs, reports, budgets, copy, correspondance...), Microsoft Word's locking and (in more recent versions) merging features have provided sufficient "version control". I've never worked somewhere where documents were the end result or on projects with 1000 people though. Much as I hate MS, they do have technologies to deal with this kind of thing without elaborate version control and publishing mechanisms. Now, sometimes you do need to edit documents in private and publish; some organisations and projects are sufficiently large or heirachical that it's necesarry. But it's not always so and having the option not to is, in smaller, organisationally-flatter environments, preferable.

Re:chmod, chown, etc.?

[Anonymous Coward]

Of course, if you have setup this correctly it would be very easy to do. First, name the groups correctly such as DAL-FIN--RW. All the dallas users should be a member of that domain group. You look at the group associated with the folder. You can easily tell that by looking at the groups.

NTFS ACLS are usually setup more complicated then they have to be from my experience. And usually, setup by a person who has no clue what they are doing.

Nested ACLS (unless it is NEEDED for some reason) should never happen. Everything under the folder is inherited permissions.

It takes a little while to set this up, but any properly setup Windows file system is easy to administer and tell who gets what.

Re:chmod, chown, etc.?

[atamido]

Figuring out who has permissions is significantly easier than you're making it out to be. The two things thrown in to intentionally confuse readers are:

1. including possibly-contradictory local
2. and inherited permissions

1 is not the problem people often think because of a rule used to simplify 'contradictory' permissions. Namely, "Deny permissions always trump anything else." So take a look at any deny permissions, and no matter what any of the other permissions say, you know that nobody in the deny permissions has access to the folder.

2 appears to be in place to confuse the reader. Inherited permissions are always displayed in the security tab. There isn't any guessing as to if there is some sort of "unknown inherited permission". It's essentially a non-issue.

Honestly, I don't know how people get by with simply Unix style permissions in a corporate environment. The simplest scenario I see all the time is there is a directory that I want one group of users to have read access to, another to have write access to, and a subset of the two groups to be denied access.

If I had to point to one aspect of Windows ACLs that are confusing, it's the way that share permissions and file permissions overlap. A share can have whatever permissions, and the files themselves can have another set of permissions entirely. Sometimes resolving between the two can be a bit confusing. Generally, relaxing share permissions, and depending on file permissions makes things easy, while keeping it safe.

Re:chmod, chown, etc.?

[ettlz]

You can quite easily manage the ACLs in XP Home using cacls.exe on the command line.

Re:chmod, chown, etc.?

[zsau]

I'm using Windows XP Professional at work (I've used GNU/Linux at home since before Windows 2000 was released, so I find new versions of Windows a little confusing).

I needed to change the permissions of a file and had exactly the same problem as the PP. Eventually I had to ask the resident Windows guru how to do it. Even he took a while to work out what was wrong and how to fix it; in the end I think he stumbled across the answer and probably couldn't tell me what to do if I asked him again.

Yes, better security...

[TinBromide]

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)

Re:Yes, better security...

[Nazlfrag]

To be fair, you can get porn on your mobile too, it just looks a lot like the porn you used to get on your C=64.

Re:Yes, better security...

[Anonymous Coward]

au contraire, I'm not familiar with $5k laptops, but even free cellphones vibrate.

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.

Re:Yes, better security...

[KC9AIC]

You're obviously not in Canada...

Re:Yes, better security...

[Anonymous Coward]

I don't know for you, but in canada providers got a solution...

Re:Yes, better security...

[Anonymous Coward]

[...]the XO's security isn't built on firewalls and antivirus software

Wow, now that's what i'd like to hear about a brand new "secure" OS, not "has a 2 way firewall" and "built-in antivirus and antimalware"...

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.

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?

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

[Tom]

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 No, but heuristics tell us that it's worse. Every new security system is worse, because it doesn't yet have the flaws found. Crypto people (who do a similar job to security people, but more professional in almost all cases) consider every new crypot broken until it has sustained some scrutiny from experts and is still standing.

I am a strong supporter of taking the same approach with new security systems: Consider them insecure until the worst bugs have been ironed out.

Re:Drastic?

[AuMatar]

There already is, minus the cover. Its marked "Power". You can add the cover via a case mod.

Re:Drastic?

[monkeydo]

Yes, it is less secure if "secure"=="verifiably secure". But that's not really a practical way of talking about security. On the day that you decide that the system is verifibly secure, it isn't really any more secure than it was when you started. However, you insurance costs should be lower.

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.

Re:Drastic?

[vadim_t]

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.

Just how does that work? A setting like that should be stored somewhere in ~/.vegastrike, that is, in the user's home directory, owned by the owner and modifiable by the owner without any permissions changes.

There's no reason why an application should require chmod'ing anything for something like that.

Re:Drastic?

[4e617474]

In normal operation, that's how it works. A sloppy package maintainer didn't bother to make sure it happened like that because there "was a workaround".

Re:Drastic?

[Tom]

Yes, it is less secure if "secure"=="verifiably secure". But that's not really a practical way of talking about security. I couldn't disagree more, but maybe we are talking about the same thing.

If you mean Formal Verification as in EAL7 then I agree, that isn't very practical.

But if what you mean is closer to what EAL3 calls "methodically tested", then that is quite practical and very useful. It's also a standardised and accepted way of talking about security. :-)

Re:Drastic?

[Alsee]

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.

Dude, there are like 667 channels on TV now.
Go outside when there's nothing on... yeah right.

-

Re:Drastic?

[Hal_Porter]

I've got this cool link to a website with dancing bunnies!

Oh BTW, if it prompts you about security, just press the button.

$5000 laptop? Pulleeze!!

[Anonymous Coward]

Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Vista?

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.

Sounds like more slashdot FUD to me. It's amazing that even though slashbots rail against FUD when Microsoft does it, they exaggerate and lie with the best of them.

This example on the front page is more evidence of that.

Re:$5000 laptop? Pulleeze!!

[p0tat03]

With all that proprietary software people love using, and the high cost of maintaining a corporate IT infrastructure, the cost-of-ownership for a single corporate laptop well exceeds $5000. It may in fact exceed $10K over its lifetime, especially if security is poor and requires constant IT intervention both in patching and rescuing/replacing dead machines.

The summary surely exaggerated, but if you think about it, companies are (in the end) paying very exorbitant prices for laptops, and most of that is for the guarantee that it will always work, or if not, the turnaround time for repair/replacement is short. I know IBM in the old days developed a lot of backend tools for ThinkPads to allow total replacement of a broken laptop with a new one - data intact and all, within hours. That costs money.

Re:$5000 laptop? Pulleeze!!

[Whiney Mac Fanboy]

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.

Re:$5000 laptop? Pulleeze!!

[Anonymous Coward]

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.

Umm, it's obvious you have no idea what you are talking about. At my company, one the largest in the world, executives are like all other employees and their computers are given and supported by the IT dept. I've seen this firsthand. Your "company account" in your scenario is fiction. If your scenario actually happened, they would be out the door pretty fast.

Please get a clue before you talk out of your ass like that. It's embarassing how clueless you are about the real world.

Re:$5000 laptop? Pulleeze!!

[failedlogic]

Hi, this is your boss. Its nice to know one person acknowledges this. My current laptop is too cheap. Its not worth as much as I know I am worth. I need a laptop with (I think my interns calll it "Bling" nowadays): 24K Gold outside and diamond encrusted keyboard keys. I have a meeting with CHAOS tomorrow and I need to impress (those groups striving for world domination, sheesh! a tough bunch). Oh did I mention? ... the supplier closes in 10 minutes. Have a flight at 06:00 tomorrow. Need it on my desk by 05:00. I just lost $100k typing this. My time is valuable. Hurry!

Re:$5000 laptop? Pulleeze!!

[Whiney Mac Fanboy]

At my company, one the largest in the world, executives are like all other employees and their computers are given and supported by the IT dept.

You're basing your view of executives from one anecdotal experience in one company - and accusing me of being "clueless about the real world"?

When you've worked at a few more companies, you'll understand that executives in different companies have different behaviour!

In your company, they sound reasonable - but you point out that you work for "one of the largest" companies in the world.

In other companies (especially medium sized ones), executives have more power, more spending discretion and less restraint. Abuse of these powers is not uncommon.

Re:$5000 laptop? Pulleeze!!

[Anonymous Coward]

You're basing your view of executives from one anecdotal experience in one company - and accusing me of being "clueless about the real world"?Actually, I've worked at two other companies, small and large, and have gotten around enough to know you just made that scenario up in your head. Most executives I've seen are on their Blackberrys more than any laptop or desktop, and the rest of their time are busy in meetings and dealing with other people. The notion of them pilfering an expensive laptop as commonplace is plainly laughable.

Re:$5000 laptop? Pulleeze!!

[Lumpy]

they also have no problem breaking every company IT rule that will get lesser being fired on the spot with their laptop and then threaten the IT guy that has to fix it if he does not fix it fast enough.

"DAMMIT I'm gonna fire you if you dont get back that report I intentionally deleted 4 weeks ago!"

A broken nose shuts up those Executive asses quite fast. Problem is that it is against IT rules to harm the Executives and leave visible marks.

These new rules make the job harder every day.

Re:$5000 laptop? Pulleeze!!

[Whiney Mac Fanboy]

*snort* is that you steve?

Re:$5000 laptop? Pulleeze!!

[gdamore]

Heh. I have "laptops" (well mobile servers might be a more accurate description) that are several times more expensive than $5000. And no, they don't run Windows.

Its amazing how expensive things get when you put a pair of UltraSPARC IIIi processors in a mobile unit.

But I also consider these units a lot more secure than a typical Windows box. They can run Trusted Solaris (though at the moment I'm only running Solaris 10 and Open Solaris on them.)

These are obviously an exceptional case (I work for the manufacturer, and wouldn't buy one for personal use), and are targetted for extreme applications. (Think DoD type applications. :-)

At the moment

[Peter Bonte]

At the moment every other OS has better security than Windows, what's new?

Re:At the moment

[physicsboy500]

At the moment every other OS has better security than Windows, what's new?

That's true... even the brand new Linux "Backdoor" distro has better security!

Re:At the moment

[Anonymous Coward]

At the moment, most childrens rooms have better security than windows - sure there may be no locks on the doors, but at least kids have the knowledge to close the doors when they want privacy! Windows may not exactly be the great advocate of open source - but lets just say all the Windows are open - and in the source community we see that as indirectly supporting us! (by building such a shitty alternative to OS).

Maybe the industry would improve things?

[gavink42]

It would be nice (but completely unexpected) if the industry followed suit and built on some of those concepts. Perhaps the result would be improved security for everyone!

Getting barbaric on their @$$es

[eviloverlordx]

So, if someone tries to break the security, does Heimtdallr come out and kick their butts?

jail is a hack

[DrSkwid]

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.

Re:jail is a hack

[kelnos]

You do realise you referenced a manpage for the Plan9 OS, which has precious little to do with Linux (or UNIX in general), right? Linux doesn't even *have* an rfork() call.

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.

Should have been in the summary:

[Anonymous Coward]

The two links given in the summary give an overview of the goals of the security system; the actual details are at http://dev.laptop.org/git.do?p=security;a=blob;hb= HEAD;f=bitfrost.txt

Re:Should have been in the summary:

[ThosLives]

Reading through the details is still a bit discouraging. They seem to still give programs the ability to specify and manage privilege.

I would rather have a system that indicated to the person installing something what types of resources an application might use, and then the person explicitly making or not making connections. For instance, in the example of solitaire used in the link above, the installer should have a picture of the application, and maybe pictures of "the network", a pen (to represent the ability to write files) that then points to certain locations, and a...i don't know what icon would represent "read"...that you'd then link to various readable resources; perhaps a lightswitch to show which other programs a program might execute....

I don't care what a program wants to access, I would want the ability to control all of it. Even things like the scheduler....I hate it when programs just start running in the background without me telling them to run (most installers are notorious for not telling you what things they install beside the main application itself).

And, by the way, if the ideas I've proposed above haven't been proposed before, I now declare them in the public domain for free use.

Re:Should have been in the summary:

[Anonymous Coward]

wow, thanks dude! you are so generous!

Re:Should have been in the summary:

[Edward Kmett]

The problem is that offering total control out of the box goes against one of their design concerns. You can't rely on a little kid to respond intelligently to a dialog box asking for explicit permission management when they can't yet read.

You would prefer total control over initial application permissions. There doesn't appear to be anything fundamental preventing an advanced user from enabling that sort of thing in a security GUI so that every time a package is installed they get prompted, its just not a viable default.

Re:Should have been in the summary:

[iamacat]

So basically, you want Interface Builder for permissions. Nice try, but such things are more suitable for developers than small kids.

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

Re:Sand dunes

[dave562]

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 ?

Given that the laptops are being given to children who will probably be doing research, it seems like they might run into problems when the kids want to "quote" from a website by "copying and pasting" from the browser app into the word processing application.

Re:Sand dunes

[Qzukk]

I tihnk I take issue with 99% of applications not needing interaction.

So you absolutely need Word to mail merge with your IM clients, which are stored in your thunderbird contact list? Does your FTP client use an excel spreadsheet to keep track of your favorite warez sites and passwords?

I can think up dozens more cases where interaction could be used but I suspect that having excel browse the web for pr0n and forward random pictures to your buddy list is not high up on the list of things it needs.

Re:Sand dunes

[jonbryce]

I do however have excel browse the web for today's stock prices, and push the values into an access database containing my financial information. This is of course what Bill Gates had in mind when he introduced this functionality. The difficult bit is letting me do this without it also doing what you describe above.

Re:Sand dunes

[complete loony]

What we're talking about here is a stable distribution. Where the OS requirements and features of each application is already well known. Limiting these applications so the OS only allows them to do what they should be doing makes perfect sense. That way, if there is some kind of exploitable code, no further damage can be done.

Re:Sand dunes

[Anonymous Coward]

Well, if you read the spec, and the picture viewer is a beign program, then you can grant the picture viewer web access permissions. It can request this access right at install time.

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:Sand dunes

[Anonymous Coward]

The idea of putting every application into a virtual machine is a good one, Every app is essentially in its own VM. They all run within a private address space. System calls to the OS let it talk outside of that address space. You'd need the exact same mechanisms to poke holes in your proposed per-app VM to access shared network, disk, or other resources.

The question that you should be asking is how do those holes get opened, what scope do they have, and how do you revoke them later. The current OS model is sandbox/VM model is sententially all-or-nothing.

see http://www.ischool.berkeley.edu/~ping/sid/design.h tml

Re:Sand dunes

[Edward Kmett]

Read more closely.

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:Sand dunes

[Fulcrum of Evil]

So you absolutely need Word to mail merge with your IM clients, which are stored in your thunderbird contact list? Does your FTP client use an excel spreadsheet to keep track of your favorite warez sites and passwords?

Quit being a tool.

Your absolutist nonsense aside, if you can't mailmerge a bunch of stuff and send it out with thunderbird, the usefulness of a computer drops a lot. It starts looking like a glorified typewriter instead of the info appliance that it is. The proper way to deal with this is to look at what interactions are dangerous and proceed from there. That and sandboxing the user so they have limited abilities to destroy the computer should make it workable.

Re:Sand dunes

[naasking]

There is (and always will be) an inverse relationship between security and usability

Speculation at best. UI design is hard just as security is hard. In fact, the difficulties of both are directly related IMO. The question is, "how can the user convey their intent to the system?", because surely the user doesn't intend to loose a virus which destroys their computer. The flip side is, "how can the system translate those intents into enforceable security properties?" In other words, it's a matter of proper user-system communication via a trusted path, ie. good UI design and a good security architecture are both necessary to achieve the desired effects. There has been some good research on secure user interfaces, the most successful of which are based on capability security principles [1],[2],[3],[4].

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.

Only because you have a monolithic view of "the application". Let me make the distinction clearer by rephrasing the usefulness of the security property we're interested in: why should the image rendering component of the application have access to the web? Really, only a small portion of the application would need net access if it needs it at all, but surely not the component that accepts a PNG file and renders it into a bitmap for display to the screen. And yet, in all systems widely in use today, the image rendering library has exactly this authority, and more (authority to delete your personal files for instance). It'd be amusing if it weren't so sad.

Most of the apps I use daily require web/internet access. I think that's only going to increase over time.

I agree, but isolating components from wielding permissions they don't need is simply necessary for good security. Fortunately, it's also good software design. :-)

[1] http://www.ischool.berkeley.edu/~ping/sid/design.h tml
[2] http://www.ischool.berkeley.edu/~ping/sid/ideus.ht ml
[3] https://addons.mozilla.org/firefox/957/
[4] http://cups.cs.cmu.edu/soups/2005/2005posters/23-y ee.pdf

Re:Sand dunes

[schon]

read your images and mass upload them to teh interweb, but only to those users who know enough to explicitly use the security interface

Or to those who are instructed by someone else, and have no idea what the repercussions are.

Re:Sand dunes

[swillden]

read your images and mass upload them to teh interweb, but only to those users who know enough to explicitly use the security interface

Or to those who are instructed by someone else, and have no idea what the repercussions are.

Yeah, well, they may be deploying 100 million laptops to poor kids around the world while simultaneously reinventing laptop hardware, software, networking, security and even creating a whole new paradigm for computer-mediated interpersonal interaction -- but trying to make social engineering impossible is a tall order even for these guys.

Re:Sand dunes

[Vintermann]

"There is (and always will be) an inverse relationship between security and usability"

But if you're going to trade one for the other, make sure you get a good deal.

Re:Sand dunes

[sloth jr]

Note that the referenced article is in error. Applications do not run in a virtual machine. They run within a chroot jail.

Internet, huh?

[Anonymous Coward]

So, this company is going to provide a bunch of children in developing companies with laptops that need to be connected to the internet on a weekly basis to authenticate it's cryptography in order to keep working. I know the article says they have long range wifi but im sure Brazil has quite a hell of a lot of land that you can't get internet access from. Oh, and talk about a tempting target for hackers. If I manage to take down your authentication site then I get to nuke how many thousands of computers?

Even XP will let you use the OS if you don't authenticate, you just aren't privy to updates.

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:More Power to Em

[Tom]

RTFA. This only protects "against" benign software. Intentionally malicious software has a few hurdles to jump over, but at least the app permission part requires the cooperation of the software in question. In other words: It protects against misbehaving or misappropriated software only.

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:More Power to Em

[99BottlesOfBeerInMyF]

RTFA. This only protects "against" benign software.

I did better than RTFA, I read the bitfrost spec. It is designed to protect against numerous types of malicious software. For example, the spec calls for protection against the machine being used to send spam by a worm. That is in fact, one of the examples in the spec.

Intentionally malicious software has a few hurdles to jump over, but at least the app permission part requires the cooperation of the software in question. In other words: It protects against misbehaving or misappropriated software only.

I'm not sure I follow you. A worm is generally classified as "malware." The "mal" in "malware" stands for "malicious" the opposite of "benign." It is certainly supposed to defend against malicious software.

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.

Why would a solitaire app need to tie things down to not run afoul of the defenses? Making a system that makes improperly designed apps hard to use is just fine, so long as they are untrusted. It encourages good coding practices. Luckily the third party software market is pretty responsive. If one app requires you to enable dozens of services by hand then it will lose in the market, as it should. I don't see the problem in the long term.

If you want a glance at that, install SELinux in non-enforcing mode and look at the log.

SELinux is a band-aid solution, running software not designed for it. If SELinux were a standard part of most Linux distros (which it likely will be some day) then this situation corrects itself. Read the spec, this provides software with their own locations for writing that is nice and contained, rather than shared space. Another nice thing is you can use VMs to allow for secure backwards compatible software during a transition (with some performance penalty).

Umm, how's this gonna work?

[kjkeefe]

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

More secure? Kind of... More usable? Ummm, no... From TFA it seems that they are securing apps by running each application in a separate VM sandbox. However, that's going to destroy usability because none of the apps will be able to talk to one another. Which sounds to me like TFA is just not digging in deep enough to what is really going on. Otherwise, they are going to be creating A LOT more work than they really need to...

Also, with such a hugely fundamental change to how applications function in the OS, what current software is going to work with it?

Re:Umm, how's this gonna work?

[Wesley Felter]

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

Re:Umm, how's this gonna work?

[Zerathdune]

Also, with such a hugely fundamental change to how applications function in the OS, what current software is going to work with it?

Good question:

The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security.

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.

Re:Umm, how's this gonna work?

[99BottlesOfBeerInMyF]

However, that's going to destroy usability because none of the apps will be able to talk to one another. Which sounds to me like TFA is just not digging in deep enough to what is really going on. Otherwise, they are going to be creating A LOT more work than they really need to...

This doesn't stop apps from talking to each other, it just allows the OS to restrict unwanted or unneeded talking between apps. I, for one, don't want my first person shooter talking to my e-mail server without my permission.

Also, with such a hugely fundamental change to how applications function in the OS, what current software is going to work with it?

Software needs to be rewritten to work with this scheme, although it is possible to have wrappers for legacy software, or VMs. For some software, this will be little or no work, while for others it will be a lot of work.

Say It Ain't So

[humphrm]

Unix security and file permissions aren't enough??? Say it ain't so, Joe!

Next we'll have dogs and cats living together.

Even worse

[imipak]

Even the crappy POSIX-compliant NT ACL model is far superior to the standard unix WRX model. No, before you start, as it happens I loathe Microsoft in particular (and proprietary vendors in general) and use Free software wherever possible even when it's technically inferior -- as is the case with filesystem permissions, where Linux has been behind Windows since NT 3.51, 1993 IIRC. Yes I know about the various security add-ons and kernel mods, grsec, SELinux, blah blah. Doesn't change a thing.

Netware was also better in this respect whilst it was still in mainstream use, despite being more of a runtime system than a real OS.

Re:Even worse

[vadim_t]

So I don't understand, what's the problem?

If you want something better than what Windows has, use SELinux. Of course, it's quite headache inducing, but it's definitely far more advanced than ACLs.

If that's too complicated, use ACLs, that's in the kernel as well.

And there are always the standard UNIX permissions to fall back on, which aren't all that bad, by the way. Yes, the ACL model is more complete, but the old UNIX permissions are more straightforward. The nice thing of RWX is that you can condense the permissions in a few characters (or digits).

AFAIK, on Windows there's no way to do something like "ls -l" and see all the permissions info on every file in the directory at once, as the ACLs can be arbitrarily long. ACLs are great in their functionality, but a pain in that you can't easily know your security settings.

For example, is it possible, in a standard Windows installation, with nothing extra added, to find out whether all the files in one directory have the same permissions and find few ones that have the wrong ones? In Linux, it's ridiculously easy, "ls -l | sort". In Windows I have no clue how to do that without getting RSI.

Re:Even worse

[patchvonbraun]

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.

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:Even worse

[Anonymous Coward]

AFAIK, on Windows there's no way to do something like "ls -l" and see all the permissions info on every file in the directory at once, as the ACLs can be arbitrarily long. ACLs are great in their functionality, but a pain in that you can't easily know your security settings.

cacls *.*

The output isn't quite as concise as 'ls -l', but the info is there.

Re:Even worse

[djcapelis]

Okay, first off:

> (for example, Windows supports things like create files, create folders, take ownership, change permissions, etc).

All of these except take ownership can be done with the standard RWX system. For multiple users changing permissions or multiple owners, read man setfacl. Take ownership can be implemented via CAP_FOWNER, or, for some types of setup, SUID or SGID... which, by the way, is not something windows allows. Windows also doesn't have symlinks, hardlinks or extended attributes such as chattr +a, chattr +i, or really any of them. (Hardlinks by the way, make the standard unix permissions system much more useful, but given that most people come over from windows and never really became at all familiar with the concept of hard links, using them is far out of their reach.)

Just because you don't know how to do this doesn't mean the capabilities to do so aren't built into the system in a well-documented and robust fashion. (Try the man pages for documentation, this is all there.)

> I doubt it would be as easy or quick to use as it would be on Windows/Novell.

Given that you haven't mastered RWX or hardlinks, I'd say this is little more than speculation. For me, the unix system is vastly easier to use as I can set it on ranges of files from my shell with a few keystrokes and windows I'd have to essentially navigate a series of really rather annoying brain-deadening dialogs. (Although to be fair, the windows command line ACL tools (yes, I know how to use them) aren't actually that bad but I'm guessing you don't know how to use those either...)

I think the one thing we can both agree on is SELinux is not the right solution for much of anything.

Re:Even worse

[rtechie]

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.

Re:Even worse

[a.d.trick]

Actually, the main Linux file-systems support POSIX ACLs (a howto for fedora, there's also a nautilus plugin if you want gui stuff). It's just that few users have any use for it, so it tends to go unnoticed. Also, because of the ability to mount drives anywhere in the file system, you can chose where to use ACLs and where it's just useless complication. I've never had any use for ACLs though, so I haven't actually tried any of these things.

As for PowerShell, I think it's more like Python or Perl than an actual shell (not that Python or Perl are bad).

Re:Even worse

[Mad Merlin]

...but then you have to maintain all the symlinks and hardlinks and make sure THEY have the proper permissions.

Symlinks don't have permissions of their own, they inherit the permissions of whatever they link to.

I can think of 4 apps on my little Linux box that REQUIRE that they be run as root, etc.

What apps? I've never run into an app that requires root when it shouldn't. Not even various commercial software makes that mistake.

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.

What distros? No distro I can think of (Gentoo, Fedora, (K)ubuntu, Suse, Debian, ...) assumes that root will be the regular user.

Re:Even worse

[Anonymous Coward]

cacls *.*

The output isn't quite as concise as 'ls -l', but the info is there

On Vista you can do cacls *.* /s and compare sddl strings.

Re:Even worse

[rtechie]

Symlinks don't have permissions of their own, they inherit the permissions of whatever they link to.

Fair enough, but you didn't answer my question: How are hardlinks supposed to contribute to security? Technically, you might argue that maintaining links is a "security" task, but that's just splitting hairs. It's still work.

What apps? I've never run into an app that requires root when it shouldn't. Not even various commercial software makes that mistake.

The KAI tunneling daemon, the CCS daemon, PAR2, and one that I can remember all want root on my Debian box. Now I might be able to fiddle them into not needing root, but I'd have to futz with lots of permissions.

Re:Even worse

[caluml]

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.

What?

Apart from binding to 1024 (why is that still a root requirement - can't we just disabled it?), most software doesn't need to be root. Please give me some examples. (I could be wrong, of course).

Re:Even worse

[Mad Merlin]

Fair enough, but you didn't answer my question: How are hardlinks supposed to contribute to security? Technically, you might argue that maintaining links is a "security" task, but that's just splitting hairs. It's still work.

I didn't attempt to answer your question.

The KAI tunneling daemon, the CCS daemon

I'm not familiar with those, but I can easily see how they would need root privileges (needing to modify routing table, scheduling jobs for other users, etc), but they both probably drop those privileges after they're no longer needed. You probably start them automatically upon boot as well, so the point is rather moot.

PAR2

This one works perfectly for me as a normal user, and I don't see any reason why it wouldn't. I didn't have to do anything special.

One Desktop per Village would be a better start

[ConfusedSelfHating]

I think it would be a lot easier to have a goal of putting one handcrankable desktop in every village. You could make something heavy, durable and difficult to steal. You may be able to set up a low bandwidth wireless connection so that isolated villages could communicate with the outside world (I'm thinking a low frequency radio signal with a lot of range, but low bandwidth). The BBC/UN/etc could broadcast news and other information on radio frequencies usually reserved for AM/FM radio. We are in such an information glut that we often forget that 2400 baud modems were useful in their day. We expect video, but text can still be very useful. The information technology needs of a Third World village are pretty limited and this would satisfy them. It would be very inexpensive and require little expertise to setup. If it failed, the consequences would be minimal. If it succeeded, then more elaborate steps could be taken.

The problem with the One Child Per Laptop is that it is too ambitous. The United States was quite capable of delivering one laptop per person trapped in New Orleans during Hurricane Katrina. Would that have solved their problem? No and that's in one of the most advanced countries in the world. If you give a laptop to a kid in Hati/Nigeria/Afghanistan, they are going to get it stolen. And that's just for the raw material of the laptop. Have you seen pictures of Chinese workers stripping old computers for their component materials? And there are countries a lot poorer than China. The idea of setting up reliable public wireless networks in the Third World is absurd. Talking someone with a non-technical university degree through a wireless setup for their house can quite frustrating. And we're supposed to believe that public wireless networks can be setup in the poorest cities in the world without a glitch? And for little money at that.

Why would we be concerned about security anyway? Wow, a poor kid just had his computer hacked and his homework was stolen. Does anyone think that any hacker would bother? It's much more likely that these laptops will be stolen and used for illegal purposes afterward. Unless they have terrible security, it won't be an issue.

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?

Re:One Desktop per Village would be a better start

[SocialWorm]

It's much more likely that these laptops will be stolen and used for illegal purposes afterward. Unless they have terrible security, it won't be an issue.

They've thought of this. These machines are essentially paperweights once they leave the factory until a student receives them. Regarding theft after that point, the full document says:

997 We do not expect the machines will be an appealing target for part resale. Save
998 for the custom display, all valuable parts of the XO laptops are soldered onto
999 the motherboard.

Also note the nearby information on the optional 'anti-theft deamon' which will shut down a laptop after some time if it's stolen.

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:One Desktop per Village would be a better start

[Fulcrum of Evil]

And we're supposed to believe that public wireless networks can be setup in the poorest cities in the world without a glitch?

Well, cellphones are a lot easier than land lines in africa - with land lines, people steal the wires.

It's much more likely that these laptops will be stolen and used for illegal purposes afterward.

Like what, exactly? If you've got roving bands of armed bandits, what the hell can a laptop do that even rates?

Re:One Desktop per Village would be a better start

[ConfusedSelfHating]

Isn't this the equivalent of saying that someone cannot discuss the merits and flaws of Windows Vista because they are not developing an operating system of their own? The ability to critique projects because you think they are impractical is one of the fundamental rights of a democracy. I like hospitals, but if I think that the construction of a hospital will be too expensive and impractical, shouldn't I be able to say that freely without being told to build my own hospital.

If the One Laptop Per Child project is beyond debate, why has it been openly rejected by India? And silently rejected by most of the world? Why shouldn't there be an incremental approach as opposed to a dramatic global deployment? Why not deploy a dozen laptop computers to a thousand schools in the participating countries and see how they are used? They don't need to be the $100 model, a cheap laptop running Linux should suffice. If they are used effectively, then expand the project. If they are stolen, broken or not used, abandon the project. The project may suit some countries and not others.

Re:One Desktop per Village would be a better start

[ConfusedSelfHating]

Like what, exactly? If you've got roving bands of armed bandits, what the hell can a laptop do that even rates?

I think your missing the forest for the trees. I actually suggest that security wouldn't be a big issue because they would be laptops for children. The closest thing that I could come to a security issue, is malicious use after it is stolen.

Well, cellphones are a lot easier than land lines in africa - with land lines, people steal the wires.

Which still doesn't make the creation of a very low cost, reliable wireless network any easier. And the various metals in the laptops make an attractive target for thieves. A thief would steal a number of laptops and sell them to someone who could strip them of the raw materials that they could sell.

Re:One Desktop per Village would be a better start

[grcumb]

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.

I don't have mod points right now, so I'll just write in support of your statement.

I live in what the UN calls a Least Developed Country. Average monthly income among the minority who are employed is less than USD 200. Yet cell phones are everywhere. They're one of the first acquisitions someone makes once they have a bit of cash. When cell phones do get stolen (it happens a lot), they get re-sold on the local market.

Phones and credit get shared widely here, and with the recent introduction of SMS ("Least Developed", remember?), communications has improved drastically. There is every reason to believe that the same or similar effects would occur with widespread access to Internet via the OLPC machines.

Re:One Desktop per Village would be a better start

[Goaway]

Isn't this the equivalent of saying that someone cannot discuss the merits and flaws of Windows Vista because they are not developing an operating system of their own?

Yeah, I thought that was the standard reply one gets when one criticizes an open-source project?

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.

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.

Re:very sceptical

[lordlod]

The OLPC security system is tackling the problem of application level security, keeping applications from doing malicious or stupid stuff.
Standard Unix permissions solve a different problem, keeping files from other users.

There is a small amount of overlap where you can make a system file root owned and not user writable to prevent damage to system files but this is entirely encompassed within the new system.

So in this case Unix permissions do not work, their shortcomings make them completely inadequate for the task because they were designed to solve a different problem.

Re:very sceptical

[Tom]

Parts of your reply hurt. Others were great. Allow me to concentrate on the ones that hurt:

* 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. This might be a language barrier, but "sandboxing" belongs to "chroot jails" conceptually. MAC is something else entirely, and while you can mix it with chroot to built pretty tough jails, it's a different concept. MAC means, in a very rough summary, that all accesses of every kind are checked all the time. It's counter-concept is DAC (discretionary access control), the standard Unix model, where access is checked only at specific points. For example, read access in Unix is checked for when you issue an fopen() call with the r bit set. It's not checked again whenever you read a byte from the file. In MAC, every read() call is also checked.

Jails, sandboxes, chroots, etc. are very useful and not new or special at all. Postfix runs in a chroot environment by default, right here on this Linux box.

* 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. Any means at all for an application to break out of a jail are playing with fire. You can quote me when the first exploit is in the wild.

* Security by default. The system is secure out of the box. That's just a marketing slogan. I know OpenBSD also uses it, but OpenBSD has years of track record to back it up.

Now, I do agree that OLPC is an incredible project. I do agree that it requires a non-traditional approach to security. I don't think it's the right environment to test a new approach to security. What if there's a horrible failure? Are they going to recall millions of machines?

All that said - I'm willing to bring the popcorn and watch the show.

Re:very sceptical

[swillden]

Parts of your reply hurt.

Sorry about that.

This might be a language barrier, but "sandboxing" belongs to "chroot jails" conceptually. MAC is something else entirely, and while you can mix it with chroot to built pretty tough jails, it's a different concept.

I'll agree I played a little loose with the terminology, but mainly because I figured people would understand "sandboxing" better than "MAC". In the sense I was using it, they are actually closely related concepts.

The notion of MAC I was referring to is that implemented by SELinux, which defines fine-grained system call access controls on a per-program basis. As you said, every system call is checked, not just some of them, but the real key differentiator with those checks is that the permissions checked do not depend on the user running the program. If program X is not allowed to read files from file system Y, it doesn't matter who runs the program, even root, the program isn't allowed to read from file system Y. In general, a given program can only perform the system calls the administrator has allowed it to use, regardless of process UID.

That is similar to the idea of a sandbox, a la Java applets, in the sense that fine-grained access control is applies to the potentially untrusted code, allowing it to do no more than what it should be allowed to do.

chroot jails, of course, can be considered as just a specific form of the sort of sandboxing I discussed. chroot affects only access to files, whereas SELinux-style MAC controls access to every system call. In fact, the "sandbox" could be used to achieve the same effect as chroot, but chroot (or, even better CLONE_NEWNS) is simpler to set up and manage.

Any means at all for an application to break out of a jail are playing with fire. You can quote me when the first exploit is in the wild.

Again, I was imprecise. When an application is installed on XO, it has a set of permissions associated with it (basically, SELinux rules, I'm guessing). When it is run, the OS enforces those rules, and there is no way for the app to "break out", barring a bug in the kernel. However, the user can use the security policy administration tool to give the application additional permissions. So, for example, even though no unsigned app is allowed to have permission to both scan the file system and use the network (it can ask for either, but not both), the user can give it permission to do both.

Now, it might be a bad idea for the user to give a lot of permissions to code from an untrusted source, but in some cases the user might actually want to do it, so the system allows them to. This obviously opens up social engineering possibilities.

That's just a marketing slogan. I know OpenBSD also uses it, but OpenBSD has years of track record to back it up.

(Referring to "secure by default"). If you read the spec, you'll find it's a design principle, not just a slogan. And given the way *all* apps are run in jails populated only by necessary supporting libraries (not even any data files!) and with minimal MAC permissions by default, it's one that's taken pretty seriously -- at least from the perspective of the design. Obviously the implementation has to be proven.

I do agree that it requires a non-traditional approach to security. I don't think it's the right environment to test a new approach to security.

I don't think it's accurate to characterize Bitfrost as a new approach. It's a collection of approaches that are well-proven in high-security systems. The only really "new" thing about it is the more thorough application, and the fact that it's being deployed on a large scale.

What if there's a horrible failure? Are they going to recall millions of machines?

The whole system can be updated in the field, from the BIOS up, either over the Internet or through USB keys that are mailed to the kid

Re:very sceptical

[cryptoguy]

This is not a new concept, but an old concept taken to a new level. It simply applies a "default deny" permission at the application level rather than at the box or network level. That's a tradeoff--just like it is at the network level. You get better security at the expense of connectivity. Maybe that is a good tradeoff to make for 6 year old kids in third world countries. And it might not be a bad idea for my Mom's computer...or all those computer owners whose machines are enlisted in someone's 'bot army.

Re:very sceptical

[Tom]

The notion of MAC I was referring to is that implemented by SELinux, which defines fine-grained system call access controls on a per-program basis. [...]

it doesn't matter who runs the program, Actually, it's a per-context basis, and it does matter who runs the program, because I can put it into different contexts based on that information. But yes, the important difference is that programs do not inherit all permissions of the user who runs them.

I still consider jails/chroot to be very different, exactly because of this. In a jail/chroot, the program still runs with all the permissions of its user, it is only limited to a part of the (file-) system.

However, the user can use the security policy administration tool to give the application additional permissions. I see. Yes, that makes much more sense. I'm more familiar with SELinux than with XO, so it appears I missed or misunderstood that part.

Obviously the implementation has to be proven. The finer details of the specification as well. I've been part of the SELinux development since shortly after its public announcement. The core principles didn't change, but a lot of design details have, and a policy from 2003 is somewhat difficult to translate into a 2006 policy (haven't yet looked into what changes 2007 brought).

Many of those changes were necessary to prevent flaws and potential holes.

Whatever else they may want to say, no one can argue that this isn't one of the grandest experiments in the history of computing. *nod*

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.

YAY for Free Software

[ZachPruckowski]

If it's good, then I'll probably see it in my Kubuntu in about a year and half (8.10 Irrepressible Iguana). See, this is what I like about free software. Borrow the good ideas from each other.

Re:YAY for Free Software

[Anonymous Coward]

You really need to submit that name.

I am still laughing
.

I'd rather hope not... they'll use it for DRM.

[gd23ka]

See subject line. They're hell-bent on locking you out of your
machine, the latest Vista antics are just the start, wait til
they become enforced in silicone.

Re:I'd rather hope not... they'll use it for DRM.

[Anonymous Coward]

Silicone is for tits. Silicon is for computers.

Re:I'd rather hope not... they'll use it for DRM.

[Anonymous Coward]

Wait until they rights manage your tits then.

Re:I'd rather hope not... they'll use it for DRM.

[Antique Geekmeister]

That's already in progress. Take a good look at the "Trusted Computing" features, and plans to use it to authenticate hardware such as hard drives and DVD drives to prevent their use by any software, OS, or tools that have not paid the money for the right software keys.

Re:I'd rather hope not... they'll use it for DRM.

[gavink42]

Yes, but we all complain about how insecure Windows is, that it requires anti-virus, etc type software. It would be really nice if we didn't have to deal with all that!

As for the DRM point, I applaud what Steve Jobs wrote the other day. If his good logic is successful in convincing folks that DRM is unneeded, then this point would be moot. Unfortunately, reality will be the real "brick to the head" when the record labels just ignore his valid points.

OLPC's Wiki page

[Anonymous Coward]

(damn Slashdot, just copy linked pages like this one!)

Bitfrost is the OLPC security platform. A non-technical introduction to the security problems we're attempting to solve, and our goals and principles in doing so, follow on this page. They're taken from the complete Bitfrost specification, which we invite you to peruse and discuss on the public OLPC security mailing list.

Introduction and summary

In 1971, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.

The 1971 version of UNIX supported the following security permissions on user files:

• non-owner can change file (write)
• non-owner can read file
• owner can change file (write)
• owner can read file
• file can be executed
• file is set-uid

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling -- almost unbelievable -- about these permissions is that they've remained virtually the only real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner -- the user -- physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.

Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and anti-virus software -- the latter assuming it's fully updated, and assuming the anti-virus makers have had time to deconstruct each latest virus and construct a defense for it.

Most technologies and approaches that constitute the Bitfr

Re:OLPC's Wiki page

[drsmithy]

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, [...]

I see political correctness continues to run rampant.

The correct gender-neutral term in English is "his" (or he, him, etc). There is no rational argument that can be mounted for using "her" (or similar) - it's both equally as "discriminatory" as "his" _and_ grammatically incorrect.

Ladies, if y'all are feeling oppressed by The Patriarchy, come up with a new word and make it an accepted part of the language. Committing the same offence you're allegedly railing against is nothing more than simple hypocrisy.

</RANT>

times change

[ReidMaynard]

People use to leave keys in their car all the time in the olden days.

think again

[Anonymous Coward]

you can do stuff on that laptop that you can't on my phone ... something porn related

Call Center Employee Addicted to Pornography, Steals Cingular Customer's ID

Mod Parent Up

[Enderandrew]

Ain't this the truth.

No, that's not it.

[xxxJonBoyxxx]

No, that's not it. ACLs aren't unique to Unix.
http://en.wikipedia.org/wiki/Access_control_list

Anyone else?

Re:No, that's not it.

[abigor]

I am responding days late, sorry...what my comment meant was that Unix LACKS ACLs. That's the difference.

A Stink-Rose by any other name...

[SilentMobius]

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?

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

[mypalmike]

Even better is the next sentence:

"If the lease expires, the XO's internet connectivity is turned off, and shortly thereafter the whole computer becomes a brick."

Broken by design.

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:A Stink-Rose by any other name...

[Anonymous Coward]

Ah! Now I see good outcome come for me! Laptop is no good. But after monsoon rain come and take down house, can send children work factory slave and use good bricks for nice new home!

People pay $5,000 for laptops?

[Colin Smith]

What do they imagine they're getting for that? Yeah yeah, I know, it's the status symbol of being able to blow $5,000 on a bit of $600 hardware.

Re:People pay $5,000 for laptops?

[Mr2001]

Yeah, it's crazy - for that much, you could almost get two 17" MacBook Pros!

Re:People pay $5,000 for laptops?

[LardBrattish]

In some countries, like Australia, you can - as a private individual - offset the cost of a laptop (but NOT a desktop) against tax. So on that basis buying a $5000 laptop offsetting 50% against tax & then selling it one year on for, say $2500 (if you can get more it's good) & then getting another makes for a very cheap way of keeping a reasonably up-to-date computer in the family ;)

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:It's not hard to do this. Just not compatible.

[fwr]

To my knowledge SELinux implements MAC (Mandatory Access Control). That is not necessarily the same thing as a virtual machine per application. Pick up a book on the CISSP certification, which I AM going to get in April. There is a lot of information about different methods of access control. From reading the A, yes I RTFA, it doesn't sound like OLPC fits into any of the standard definitions (DAC, MAC, RBAC). It sounds closest to RBAC than the others, but it doesn't really fit that model either. I'd like to hear from other security professionals how they would categorize OLPC, but I think we would need more information first.

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

[swillden]

To my knowledge SELinux implements MAC (Mandatory Access Control). That is not necessarily the same thing as a virtual machine per application.

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.

It sounds closest to RBAC than the others, but it doesn't really fit that model either.

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.

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

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

[swillden]

What interests me is the classification of this security model to traditional models, and if it fits at all or would introduce a new paradigm.

I think it's pretty clear, as another poster pointed out, that Bifrost is primarily SELinux plus a particular policy set, an approach to "jailing" apps and some other bits related to system activation and theft deterrence.

SELinux is generally described as being an implementation of MAC, which is why I said that Bifrost is MAC.

However, Bifrost isn't an access control model, it's an amalgam of MAC and DAC as far as access control goes, with some other stuff that isn't access control related, per se, and some bits that might be called "User Access Control". Bifrost arranges it so that even if the owner of a file has given permission for the user to modify it (DAC), and administrative security policies allow the user and process to modify it (MAC), the program still cannot modify the file unless the user sitting at the keyboard authorizes it. Oh and Bifrost also throws in stuff about automatic versioning of files so that a malicious or subverted app can't really delete or scramble your files -- because you can always just get the old version back, and DOS prevention that stops programs from consuming all resources, even if they're actually allowed to use those resources.

I'd say that Bifrost is an overarching security model that uses implementations of various access control models to accomplish specific goals, rather than being a new access control model.

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

[Animats]

I think it's pretty clear, as another poster pointed out, that Bifrost is primarily SELinux plus a particular policy set, an approach to "jailing" apps and some other bits related to system activation and theft deterrence.

It's not the machinery that's the problem. It's getting the apps to live within the security policy that's the problem.

Suppose we wanted to build a secure Firefox to run in a jail. For each page, we create a jailed process that has permission to write to one window on the screen and to talk to one host on the Internet, and very little else. That's a strong basis for a secure browser. And it will work fine for most pages.

So what doesn't work any more? Cookies - the jailed process can't access any persistent state. Cacheing, although we could have a separate cache file for each site and make that work securely. Mashups - can't talk to more than one site. Off-site image links - ditto. Downloads - you can download, and maybe even run something in a subprocess, but when it exits, the download is lost. Tabbed browsing - puts multiple sites in one window.

Those are the real problems.

But for the OLPC system, it might be appropriate to have a browser with those restrictions. Educational content doesn't really need any of those features. On a machine with no hard drive, like the OLPC machine, you don't want to be permanently downloading much anyway.

It would make sense, though, to have that jailing capability in a browser and use it for secure pages. You don't want your online banking page in a mashup or frame, you don't want to download a game from it, and you don't want it cached.

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

[swillden]

I don't think the issues you point out are real problems -- they just indicate that the web browser needs a little bit more mapped into its jail upon startup. To a first approximation, it needs the .mozilla directory mapped in -- that takes care of cache, cookies, preferences, etc. Perhaps you might even be able to pare it down a bit more than that, but the key is to give it the files it needs, without giving it free access to everything in the file system that happens to be readable by the user.

Of course, when the user wants to, say, upload a file through the web browser, then the Bitfrost file selection mechanism would be used to give the user access to that specific file.

As the subject line says, this stuff isn't hard, and the Bitfrost approach to it is, IMO, quite elegant, but the difficulty comes from the fact that it will be hard to retrofit onto existing apps. Firefox (or some web browser, anyway) is an application that is sufficiently important that it makes sense to put in the effort required, but to apply this approach to a typical Linux system would break damn near everything. Luckily, OLPC doesn't have to care about compatibility with the larger world of existing applications.

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

[Animats]

To a first approximation, it needs the .mozilla directory mapped in -- that takes care of cache, cookies, preferences, etc.

That breaks the security model. Now information can escape from the jail and contaminate other browser instances. In fact, if you can write the .mozilla directory, you can make Mozilla/Firefox do anything. You can change the security preferences, add plugins, and put in security holes.

It's not that easy.

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

[swillden]

That breaks the security model. Now information can escape from the jail and contaminate other browser instances.

The web browser is indeed an application that doesn't benefit as much from the Bitfrost security model as most other applications. I don't know that I'd call that "breaking" the security model, though -- the browser still benefits, just not as much as other apps. That's why Ivan (the designer of Bitfrost) is working with the Mozilla team to find ways to improve the security within the browser. I'm sure he has some good ideas.

Ivan's key response to your point, though, is that although browser bugs may permit data that was sent to/received from one site to be revealed to another, it still doesn't permit a malicious site from accessing any of the user's other data, or doing any of a number of other malicious things. It's not perfect, of course, but it's a big improvement.

In fact, if you can write the .mozilla directory, you can make Mozilla/Firefox do anything. You can change the security preferences, add plugins, and put in security holes.

Yes -- but anything you do will only be effective in the context of the browser and whatever files the user chooses to make available to the browser. And if some work can be done on making the browser more effectively isolate files related to one site from every other site, then many of the attacks you're thinking of will also be restricted. I don't know what may or may not be possible in this respect. Perhaps each URL can cause a separate gecko instance to be invoked, into which could be mapped just the set of files (cache, cookies, etc.) related to that URL. That would depend on how much startup time and memory overhead each instance has. Perhaps there are other options.

It will be interesting to see what comes out of the discussions between the Mozilla team and the OLPC security team.

It's not that easy.

What's "not that easy"? I was referring to making the browser run acceptably within the security model, i.e. that the security model need not make it impossible to run a web browser. You have turned the discussion to securing user data related to one web site from other sites. Also a valid concern, of course, but even if it couldn't be managed, the browser would still benefit from the Bitfrost security model, and wouldn't be constrained by it.

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:Windows ACL permissions are nice

[Fulcrum of Evil]

Pity they're so badly set by default. Unix could do with allowing groups within groups.

Not really. You still only have one group acl for a given file.

Re:Windows ACL permissions are nice

[walt-sjc]

Exactly, which means that you can't give one group full control, and another read only. You really do need full ACL's to do it right, and more than just RWXSst.

A couple of silly questions here...

[Anonymous Coward]

Who are Pentagram? Why is the XO logo written as the jolly roger sign? Silly, I know, but still pretty fucking weird.

I know several businesses & governments

[Colin Smith]

Who would love this feature.

Re:I know several businesses & governments

[LuckyStarr]

Funny how the XO gets sold to governments and not geeks.

It isn't about ACLs.

[jhantin]

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.

Takes Big Brother to the next level

[Anonymous Coward]

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

Re:Takes Big Brother to the next level

[Zspdude]

You've never lived in a third world country, have you?

$100 is peanuts in the 1st world. When it's half a year's salary, that makes all the difference. Would you give a ten year old child a $25,000 piece of equipment to play with for 'educational' purposes? If you can barely afford to feed them and pay their school fees in the first place, it becomes quite simple. You take it away, treat their sick grandmother, and (maybe) you pay their school fees. Oh, and you buy them a textbook. Which is then 'borrowed' by the teacher, who couldn't afford one.

Unless there are strong measures in place to ensure that the laptop stays in the hands of the child it was given to, it won't. How do you identify the child it was given to? A password is useless - any parent (or in some cultures, any adult) will be able to convince a ten year old to surrender their password. Would you let a ten year old be exclusively responsible for remembering the password that activates a $25,000 piece of equipment?

I haven't even mentioned (external)theft because the potential for it should be so incredibly obvious. From a security perspective, protecting the laptop from the parents is a far more difficult problem.

Your comment about the RIAA is ridiculous. I have to chalk it up to your own personal vendetta. I can think of a few governments, however, which might possibly abuse this program.

- Scott

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:Two Cents

[rrohbeck]

>2. Would you (and the rest of /.ers) be willing to purchase 1 of these laptops for $200?
Definitely. It will be *the* geek toy for a while. If I have ssh and VNC it'll be worth it. And with a PDF viewer it should be a decent ebook reader - assuming the display is good.

Re:Two Cents

[seandiggity]

Yeah I woulda been more willing to buy one before these DRM-like shenanigans...Beyond that, there are some other pretty good criticisms of the project and I'm not sure I should support it monetarily.

Re:Two Cents

[Anonymous Coward]

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.

I believe someone already suggested this idea, but with a "developed world" price of $300 -- and the answer was that the project was not interested in selling any laptops to non-Third-World users.

One Treacherous computer per Child

[Marcion]

Don't get me wrong I think the project is the best thing since Tim Berners Lee invented the WWW, however:

"The sole purpose of these keys will be to verify the integrity of bundled software and content."

Sounds a bit like DRM? What if the child gets bored and decides to install another Linux distribution?

"If the lease expires, the XO's internet connectivity is turned off, and shortly thereafter the whole computer becomes a brick."

Er nice...

Re:One Treacherous computer per Child

[kelnos]

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.

Re:One Treacherous computer per Child

[Marcion]

>Are you just trolling?

No, I have serious questions about this one point.

>As for installing another Linux distribution, would that even be possible at present?

Yeah certainly, you could do any of the Gentoo based ones or setup the bootloader yourself and install any. While out here everyone upgrades their laptop every three years, these things are going to be out there for a longer time.

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

Well if that is true then that is okay. If it is in software then it will not stop more than the causal thief.

Parent Comment is GOOD

[ratboy666]

Sorry, I don't have mod points.

But, yes, I find ACLs *very* hard to manage. In general, RWX is easy to work with -- may need to create extra groups, but I can follow, document, and understand.

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.

Re:It's just the usual Trusted Computing fallacy

[Fulcrum of Evil]

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.

You've got it all wrong - this will be a technology bureaucracy, with programmers' products allowed to run only on the brick they built it on until blessed by some corporate functionary. Basically, it's Brazil.

Re:It's just the usual Trusted Computing fallacy

[statusbar]

Maybe the vision of the world 'where only the priesthood are granted programming licenses' is where we are going. Not really a priesthood, but authorized, approved, educated and vetted by the regime-of-the-day, "Programmers".

People as consumers and workers, not as citizens or producers.

Especially those third world coloured kids who need to be taught how to 'plug in to the net' and 'consume information' - but giving them the freedom to create or extend technology is too scary for 'us'.

--jeffk++

Re:It's just the usual Trusted Computing fallacy

[Alsee]

I am one of the most vocal opponents of Trusted Computing around. Trusted Computing is evil, and far more dangerous of a threat than even most opponents realize. I am a programmer, I have read the full (several hundred pages) Trusted Platform Module technical specifications, and I have read the detailed OLPC security document.

Your fear of the OLPC security design is thankfully misplaced. I was quite impressed by it. I read through it with with my tinfoil hat firmly in place, and I was pleasantly surprised at how thoroughly evil-free it was. They really did design the system for students to become programmers and write their own software. Programs absolutely do *not* require a signature to run. To quote the OLPC security system document:

the scenario where a child develops some software and wishes to share it with her friends becomes a natural one, and one that needs to be well-supported.

Simply by going to the built-in security panel, they can unlock, copy, and re-write the entire operating system. They can do so AT WILL. All they have to do is engage the P_SF_RUN flag. The original operating system is still stored in the background, but any change to the operating system becomes the new and "permanent" OS. The next time you boot up, you boot up into your new customized operating system. If you disengage the P_SF_RUN flag from the security panel, you go back to the stored copy of the original operating system.

The only part of the system that they are locked out of... the only part of the system they can't unlock themselves and rewrite at will... are the BIOS and the backup copy of the original operating system. However they do allow kids to request a developer key. This key allows them to overwrite the BIOS itself. (It also obviously allows you to modify or wipe the backup copy of the original operating system.) The only limitation is that the developer key only unlocks the single computer... you can't write a virus and use your key to unlock and overwrite the BIOS on everyone else's computers.

And even if you don't have a developer key, most of the security aspects embedded in the BIOS can be overridden from the security panel.

About the only thing that can't ultimately be overridden is the security point that the built-in microphone and the built-in video camera are physically hardwired to LEDs to reveal when they are active. Unless you crack the case and physically cut the wire, there will always be a warning light when the microphone or camera are active.

-------

I would also like to clear up some unfortunately common misunderstandings about Trusted Computing. Trusted Computing is as evil as all hell, it's just not evil in the way many people think that it is evil.

programs are going to need to be "signed" by an "authority" before they can be executed.

The minute you actually grant your "appliance" Turing Completeness, you've lost its Trusted Computing properties.

Untrue, and untrue. Software does not need to be signed to run on a Trusted Computer. A Trusted Computer can and will run any software you ask it to run. A Trusted Computer can do anything and everything a normal computer can do.

Think about it.... the first and foremost goal of the Trusted Computing movement is Global Conquest... to displace normal computers. No one would would ever move to a Trusted Computer if it couldn't run the vast library of existing software. No one would move to a Trusted Computer if it were virtually impossible for anyone to write new software for it.

If this myth were true... if Trusted Computers only ran signed software... then the entire movement would be dead in the water. Trusted Computing would be NO THREAT AT ALL. The fact that Trusted Computers can run unsigned software, the fact that Trusted Computers can do anything and everything a normal computer can do, that doesn't mean they are n

Origin/rationale for name

[dewarrn1]

From the spec linked from the article, section 11:

1227 In Norse mythology, Bifrost is the bridge which keeps mortals, inhabitants of
1228 the realm of Midgard, from venturing into Asgard, the realm of the gods. In
1229 effect, Bifrost is a powerful security system designed to keep out unwanted
1230 intruders.
1231
1232 This is not why the OLPC security platform's name is a play on the name of the
1233 mythical bridge, however. What's particularly interesting about Bifrost is a
1234 story that 12th century Icelandic historian and poet Snorri Sturluson tells in
1235 the first part of his poetics manual called the Prose Edda. Here is the
1236 relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:
1237
1238 Then said Gangleri: "What is the way to heaven from earth?"
1239
1240 Then Harr answered, and laughed aloud: "Now, that is not wisely asked; has
1241 it not been told thee, that the gods made a bridge from earth, to heaven,
1242 called Bifrost? Thou must have seen it; it may be that ye call it rainbow.'
1243 It is of three colors, and very strong, and made with cunning and with more
1244 magic art than other works of craftsmanship. But strong as it is, yet must
1245 it be broken, when the sons of Muspell shall go forth harrying and ride it,
1246 and swim their horses over great rivers; thus they shall proceed."
1247
1248 Then said Gangleri: "To my thinking the gods did not build the bridge
1249 honestly, seeing that it could be broken, and they able to make it as they
1250 would."
1251
1252 Then Harr replied: "The gods are not deserving of reproof because of this
1253 work of skill: a good bridge is Bifrost, but nothing in this world is of
1254 such nature that it may be relied on when the sons of Muspell go
1255 a-harrying."
1256
1257 This story is quite remarkable, as it amounts to a 13th century recognition of
1258 the idea that there's no such thing as a perfect security system.

Re:Origin/rationale for name

[Vintermann]

The sons of Muspell are the fire giants which according to Norse mythology will burn heaven and earth at Ragnarok. If something is safe up to armageddon, it's probably safe enough for our purposes.

"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:The one major difference to MS "trusted" comput

[Cheesey]

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.

Yes? But the article also says:

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.

Surely this is only possible with a TCPA-style system? Otherwise the thief could just disable the check after stealing the machine. It sounds worse than Windows Genuine Advantage: that doesn't try to stop you installing another OS, and it won't kill your machine if you can't go online for some reason.

Shortly thereafter the whole computer becomes a brick.

Defective by design?

[Cheesey]

Shortly thereafter the whole computer becomes a brick.

The article strongly implies that the OLPC will be defective by design, as RMS would say. A central authentication system that locks users out if they don't authenticate regularly, being used in an environment without reliable net access? Yeah, great idea. Can't see any problems with that. Does it also prevent users loading their own applications or custom kernels?

Would someone from the OLPC project care to comment on this? What precautions have been taken to ensure that users are still in control of their machines, and can easily work around all digital restrictions if they want to? How does a user recover a machine that has been "bricked" by failed authentication or a WGA-style glitch?

Re:Defective by design?

[tsq]

The article strongly implies that the OLPC will be defective by design, as RMS would say. A central authentication system that locks users out if they don't authenticate regularly, being used in an environment without reliable net access? Yeah, great idea. Can't see any problems with that. Does it also prevent users loading their own applications or custom kernels?

Considering that the laptops are designed to encourage users to program their own applications (to the point of having a dedicated "view source" button), and users can be given a "developer key" of sorts that lets them reflash their firmware, I think that it most certainly does not prevent loading custom kernels and applications.

Re:Defective by design?

[Anonymous Coward]

I know you don't necessarily mean this but the lock-out doesn't need to be kernel based -- it could be elsewhere in the software/hardware.

Also I'm not sure if RMS would be against this. There's that exception in GPLv2 about not giving source to users when the user doesn't own the hardware (eg in a business setting running a gpl app, or in a school). It's frowned upon, sure, but it might not be against GPLv3 rules.

Sigh. Hidden DRM plan.

[fang2415]

FTFA:

Beyond cyberthreats, the XO laptop will have an anti-theft system designed to render stolen laptops useless. Each XO is assigned a "lease," secured by cryptography, that allows it to operate for a limited period of time. The laptop connects to the internet daily and checks in with a country-specific server to see if it's been reported stolen. If not, the lease is extended another few weeks.

If the lease expires, the XO's internet connectivity is turned off, and shortly thereafter the whole computer becomes a brick. In the case of an area without internet connectivity, a local school can extend the lease from its own server by Wi-Fi or with a USB dongle.

I've been hearing that they were going to do this for a while, and I think it's a terrible idea that will kill a lot of the potential of this wonderful project. What happens if these kids go to another area for a month or two and want to take the thing with them? Tough, it's a brick. Not to mention if they want to keep it and take it out of area after they graduate.

There's also this deeply worrying gem:

Users can manually assign more power to a particular program through the security control panel, but even there, they are limited.

"You cannot request a set of permissions that let you do bad things," Krstic said.

So much for a computer that students will have complete control over, can take everything apart and put it back together, etc. For a project so focussed on empowering kids as users, these two parts of an otherwise promising security plan sound an awful lot like the computer having control over the user, not the other way around.

I hope I've got this wrong, I hope that we aren't actually introducing third world kids to the world of DRM and Treacherous Computing, where "their" machines do things they can't control, where they "lease", not own. If so, it's really too bad. Yet another missed opportunity...

Re: Hard Links

[Ayanami Rei]

Hard links don't help in general with the unix security model since they share an inode (where the owner, group, and mode is located). Extra hard links are just extra directory entries.
The one exception is when the location of a file is stored in two seperate folders with different traverse settings (execute on directories) which can control access by ability-to-name.

But that's an all or nothing method, and you can't hardlink subdirectories so you end up linking files individually, which is a bad approach unless automated as part of a file management system.

SELinux _is_ a good solution, provided that developers or third parties care enough to develop robust profiles for applications, with nods to different roles a user might take on in day to day usage of that software, and tailoring access needs to that. Fedora is thankfully going down this path, and establishing some best practices.

In SELinux, who can do what is determined largely by (multiple, simultaneous) user roles, application roles, and allowed transitions between them. Application roles that act on behalf of users are how requested capabilities on objects are granted. You grant an application role (called context) the ability to do operations on types of objects. Thus you tag files with object types (which is only important for file activity; other important types of permissions for operations on non-file objects can be delineated).

I think what's holding that back is that Administrators suffer from the lack of good tools to manipulate the various security descriptors for objects and to do what-if analysis.

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) 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:There are things in the spec I object to...

[uufnord]

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

This crypto key doesn't refer to anything directly related to X, it has to do with the installer. The spec says:

450 As a final note, programs cryptographically signed by OLPC or the
451 individual countries may bypass the permission request limits, and request
452 any permissions they wish at installation time.


So it's actually a bit worse than your scenario. Any program with the correct crypto key 0wnz0rz the b0x0rz, including X, the network, the audio/video, the file store, etc.

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

[IamTheRealMike]

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.

Yes. That's why it's a protected operation and requires signing.

Re:The one major difference to MS "trusted" comput

[kelnos]

If you read a little higher in the spec, it says the anti-theft system is implemented as a system daemon that not even root can kill (so apparently the kernel was modified for this to make that app special). Looks like it's entirely done in software, and the OLPC country managers have to even specifically ask that it be enabled for their laptops.

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.

There goes the glass house neighborhood

[Anonymous Coward]

Damn, now that Lunix is getting primed to lose it's security through obscurity, we will soon see the flood waters gush through the sieve of their security.

Quick! Somebody make another text editor!

Re:The one major difference to MS "trusted" comput

[Cheesey]

Thanks for the info.

Given that, it doesn't sound bad. Restrictions aren't a problem as long as the user can turn them off.

irregardless

[Anonymous Coward]

FYI, "irregardless" is not generally considered correct or appropriate English. You may want to catch yourself when you start to say or write it, and consider replacing it with either "irrespective" or "regardless."

SELinux

[bluefoxlucid]

So, they implemented SELinux/grsecurity/RSBAC policy. As in, not the system, but a policy file.

Thailand?

[Anonymous Coward]

"Millions of XO laptops are expected to go into production late in 2007, with Thailand, Brazil, Uruguay and Rwanda, among others, signed up for the launch."

Didn't Thailand pull out of the project because they're trying to strike a deal with Microsoft? Are they back in now?

Re:Sigh. Hidden DRM plan.

[uufnord]

re: anti-theft system
I think it's a terrible idea that will kill a lot of the potential of this wonderful project.

The spec says this:
971 The OLPC project has received very strong requests from certain countries
972 considering joining the program to provide a powerful anti-theft service that
973 would act as a theft deterrent against most thieves.
974
975 We provide such a service for interested countries to enable on the laptops.

So it looks like the decision is a political one. It suggests to me, though, that it would be possible to get or purchase (or steal) one from a country that isn't as paranoid.

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

I think that's incorrect, and I think the article might have gotten it wrong. The spec mentions that there are sets of permissions that will be denied at install time; however, it also claims that one of it's design goals is "no lockdown" and that "there must exist a way for these
211 security systems to be disabled." That's pretty clear to me. If program X asks to install itself with P_KILL_BOB AND P_KILL_ME, then it will be rejected from the installation. It needs to install itself with either P_KILL_BOB OR P_KILL_ME, but not both, because only one of us needs to die.

I think the article may have taken Krstic's comment out of context.

Ya know, maybe they could add "No Bricks" to their design goals... Just a thought.

Who holds the keys?

[Louis Guerin]

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

RTFA - this is not DRM or Trusted Computing

[schwaang]

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.

Umm, NO.

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:

The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user.

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

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 worse than that, it prevents app partition

[filesiteguy]

You have an extremely valid point, which I didn't even think of in my original post. Given that almost any modern app - save a "Hello World" tutorial - is going to communicate on some level with other applications, this model may get very old quickly. Even in my simplistic Linux system, I'm running Firefox, which is communicating processes and threads with the Window Manager KDE, and the various sub-components of that.

It is too late to think about this now.

uh, FYI, Linux DOES have ACLs now

[r00t]

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.

One Lease Per Child

[bitspotter]

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.

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

Wow. So someone else has the power to brick my machine remotely? I thought this was MY laptop? This sounds more like a loan than a gift. It sounds way to close to some DRM vendor's wet dream than a teaching tool.

Re:One Lease Per Child

[lachlan76]

Wow. So someone else has the power to brick my machine remotely?

No. It only bricks it IF all three of the following are fulfilled:

1. The government that purchased the laptop asked the OLPC people to activate the feature.
2. The owner hasn't disabled it.
3. The laptop hasn't had access to the server for a specific amount of time (three months, I believe)

The owner is easily able to turn this off. It's nothing to do with DRM.

Re:One Lease Per Child

[smoker2]

I thought this was MY laptop? This sounds more like a loan than a gift.

Can you point me to where they say that these laptops are given *in perpetuity* to the children ? They are learning aids, bought by governments, to help children of school age. I fully expect these devices to be used in the same way as school books are now - ie. when you leave school, you leave the book/laptop behind for the next generation. These are not designed for use in "it's mine, it's all mine, US of A" !

not a new security system

[r00t]

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.

Re:not a new security system

[Tom]

The concept, called mandatory access control, goes back decades. [...]
A few years back, the NSA wrote an implementation of this for Linux. It's called SE Linux. I'm dimly aware of that. I've given some speeches on SELinux back in 2003/2004 and contributed some patches and policies.

Nothing in TFA makes me believe they've done what four years of NSA-supported SELinux development couldn't do: Make SELinux a viable option for a non-SELinux-expert sysadmin or user.

I'll be watching.

Re:not a new security system

[r00t]

OK, so you know SE Linux exists and isn't anything new. It works great.

Though with a mild policy, Fedora has enabled it by default since Fedora Core 5.

OLPC is willing to adjust apps to be tolerant of high security. That makes the SE Linux UI much easier to do.

Re:not a new security system

[Tom]

Try writing your own, say, IRC server. Then write a policy for it. Then we'll talk again. :-)

(disclaimer: I've written policies for mysql, subversion and others. It's not that tricky - if you are trained in SELinux. I doubt any of the professional sysadmins at my company who've no SELinux experience could do it in less than a full week.)

the kernel support is there

[r00t]

If you edited your SE Linux policy, you'd be half-way there. The other part, jailing the apps, requires severe GNOME/KDE hacking.

didn't read/comprehend TFA, did you?

[r00t]

The child can request a laptop-specific developer key.

The kernel and firmware can be upgraded via this key. (writing regular apps does not require the key)

There is a 14-day waiting period to give time for stolen laptops to be reported. Keys are obviously not provided for stolen laptops.

The GPLv3 merly requires that the key be provided upon request. I don't think 14 days would be disqualifying. In any case, neither the kernel nor the firmware are GPLv3.

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.

It well may be time to think about a new way

[ocularb0b]

Beyond the up's and down's of the OLPC/Bitfrost approach. It seems very valid to suggest that it is time to look at the lower level of how system security is handled.
The rate that new networking systems are developed and distributed is alarmingly high and seemingly well past, or at least just in front of, our ability to secure these systems.
OS level security that accounts for the fact that the OS is connected to a virtually uncountable number of other(friendly or unfriendly) systems seems perfectly logical if not down right critical to the health and safety of what has quickly become a monstrously huge, and shared, system of computers and data.

I don't think the OLPC/Bitfrost system makes much sense for all of us, but t looks like a very solid way for a user who's needs aren't much past the capabilities of a smartphone or PDA (as nearly as i can tell thats just about all the OLPC really is, with a bigger screen).
I hope to see some other reworks of the main security model more tailored to the current, and supposed future, reality of where our systems are.

What if the OS consisted of Virtual systems, one that is local and one that is networked? The networked VirtualOS is jailed and unaware of any other OS's that are not likewize networked, and a LocalOS that is aware only of itself and the networked VirtualOS that it hosts. "Local" could access neteworked data by proxy, but the networked VirtualOS could never explicitly modify the LocalOS.
Does that make any kind of sense?

Yeah so there's my bit.
any thoughts ?

even worse

[r00t]

They used "she" in a reference to the original UNIX developers.

Let's see, which one is the woman? Ken, Dennis, or Brian?

Note: the names are not Kendra, Denise, and Brianna!

These guys are called "greybeards" even, because they have grey beards. Transvestite bearded ladies? Eeeew.

I'm reminded of the icky 9-11 statue showing 3 firefighters raising a US flag over the ruins of the World Trade Center. In reality, all were white. In the statue: black, hispanic, asian.

Re:It's worse than that, it prevents app partition

[arodland]

Your appositive is faulty. KDE ain't a window manager. KWin is though.

Re:It's worse than that, it prevents app partition

[FishWithAHammer]

And your pedantry is stupid.

There are distro optimized for small RAM.

[DrYak]

As for installing another Linux distribution, would that even be possible at present?

Yes, you couldn't install a full fledged distro, like Debian, Opensuse, Mandriva, Ubuntu, in all it's Gnome/KDE glory, due to the small memory capacity, etc. ...BUT!...
The strengh of linux is it's customizability, and there are already several distros specially customized for small memory foot prints, etc. Like Damn Small Linux (Debian variant specially tuned to provide a nice graphic desktop even on computers as old as 486 with 24MB ram. And if it can run on that piece of trash, surely it can run on the OLPC (even if it can't run all special extensions like the dual resolution e-ink screen).

I don't know why, but every time I read "Linux" on the web, it automatically means "RedHat", "with both KDE and GNOME installed".

Try right-clicking 1000 files....

[Joce640k]

Try right-clicking 1000 files, it gets real old, real fast... ...and that's the real problem with GUIs. They're fine for personal productivity apps but useless for administrative work.

Re:Try right-clicking 1000 files....

[Vintermann]

Ctrl-A, Properties. Voila, set properties for all the 1000 files at once.

Re:Try right-clicking 1000 files....

[illtud]

Ctrl-A, Properties. Voila, set properties for all the 1000 files at once.

Yes, set. Now try it for viewing properties (which I'd argue you'd want to do a lot more often) without dropping down to the command-line tools. ACLs can be good and crunchy, but they can quickly turn into an auditing nightmare without strict discipline - ie more than I've seen in most situations. And when you need CACLS, good luck processing that output easily.

Spend the rest of your time in hypervisor lockup

[gd23ka]

I'd rather hang on to x-y-z antivirus than have a secure
digital fortress where the guards tell _me_ what to do.

Where does it say that?

[Joce640k]

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

security?

[Anonymous Coward]

if it's so secure how come the web browser doesn't display the URL a person is on? exposing them to phishing.

Meanwhile, with Microsoft...

[DrYak]

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.

Whereas, with Microsoft "trusted computing" schemes:
D@rkSh4d0wSep1roth1992, as a 1337 ScriptKiddie and Pwnz0rs of your box, can get around it and botnet it.
OR :
Sony, as owner of the disc for which you just bough a "Limited Listening License" and therefore, by extension, owner of anything you may try to play it on, can get around it and root-kit it.
OR :
The **AAs as owner of the government that they paid to create DMCA, can legally get around it, and spy everything they can just to gather enough evidence (a.k.a. false-positives) to sue your 5 ears old's communist pirate ass for copyright infringement.
OR :
FBI / CIA / NSA / Men-In-Blacks / NTAC / World conspiracy of black copters / a small girl called "Jenny", as owner of the divine right to protect justice and owner of a device used to brainwash microsoft programmers, can get around it using backdoors specially planted for that purpose and spy every information needed to chase you, guilty unless proven otherwise, god-hating, porno-terrorist. Think of the Children !
OR :
Software bugs, as true owner of your OS and hardware, don't need to get around it (they're already in the OS) and can fuck up your peripherals and drive the machine into spontaneous combustion, as you helplessly look at it with an astonished expression, discovering what actually the "Wow" factor meant for Vista.
OR :
...etc...

Re:Sigh. Hidden DRM plan.

[nagora]

What happens if these kids go to another area for a month or two and want to take the thing with them?

They switch that feature off until they get back.

TWW

chflags?

[swehack]

No one seems to be mentioning chflags, first appeared in 4.4BSD and they make it possible for a user to protect files from themselves, even from root. I haven't read the full Bitfrost specs yet but from the short wiki introduction it sounds like they're missing things that protect files from the processes run by the owner of the files. Chflags does this.

The lead architect says so.

[Anonymous Coward]

Under BitFrost, every program runs in its own virtual machine with a limited set of permissions. Thus a picture viewer can't access the web, so even if a hacker comes up with an exploit that lets him control the program, he couldn't use it to grab all the photos on the laptop and upload them to the internet.

That seems pretty clear to me. Programs don't have access to the web, in other words they have no access to sockets. And that means no IPC, so programs have to be non-communicating and hence monolithic by default.

The article also says that all default security blocks can be overridden, but unless an application developer knows about the security system as well then the natural design for his app will be a monolithic one.

And to remove any further doubt, here are the lead architect's own words:

Still, Krstic admits there's a drawback to his system: It limits interactions between applications.

"This kind of model makes it more difficult for glue between applications to be built," Krstic said. "But 99 percent don't need glue."

Re:The lead architect says so.

[drinkypoo]

Under BitFrost, every program runs in its own virtual machine with a limited set of permissions. Thus a picture viewer can't access the web, so even if a hacker comes up with an exploit that lets him control the program, he couldn't use it to grab all the photos on the laptop and upload them to the internet.

That seems pretty clear to me. Programs don't have access to the web, in other words they have no access to sockets. And that means no IPC, so programs have to be non-communicating and hence monolithic by default.

Dude. Think about what you're saying. No access to the web doesn't mean no sockets. First of all, there's at least two kinds of sockets. The kind you're thinking of is apparently TCP/IP sockets. There's also Unix Domain sockets. Programs also often communicate via named pipes. But even in the case of TCP/IP, the application could simply be set to only allow use of the network when connecting to localhost. See how easy that is?

SElinux provides the same sort of functionality, and it doesn't stop computers from working unless you misconfigure it.

The article also says that all default security blocks can be overridden, but unless an application developer knows about the security system as well then the natural design for his app will be a monolithic one.

What makes you assume that it must be handled by the application developer? In fact, having the application itself have control over its permissions would blow the whole scheme. It will likely be controlled by some centralized database (even if it's just a collection of flat files) which will determine what capabilities programs are permitted to have.

"This kind of model makes it more difficult for glue between applications to be built," Krstic said. "But 99 percent don't need glue."

More difficult. Not impossible. If I latch your gate, it makes it more difficult to open. It doesn't make it what I would actually call "difficult" unless there's something wrong with your latch. And no one has successfully shown yet (at least in the thread of this conversation) that there is something wrong with this security mechanism.

You are simply FUDding and until you actually know something about this system, why don't you just save your FUD for something else?

Re:The lead architect says so.

[Anonymous Coward]

The OP believed TFA, and Krstic in particular. You don't.

You seem to live in your own little world, where you know best regardless of all evidence to the contrary.

You seem to believe that despite the lead architect saying that this will affect 99% of applications by denying them the glue to talk to other processes (by design), that actually he's lying and that it won't, and that instead apps will have exactly the same freedom to interact with other processes as in regular Unix.

Instead of complaining at the OP's acceptance of Krstic's words at face value, why not take it up with Krstic? Why would he lie about the 99% effect that his new security policies make? And why the hell should anyone consider that your opinion overrides the lead architect's own words?

If anyone is FUD'ing, it's you, since you are directly contradicting what the lead architect wrote and claiming that he has not implemented the security controls that he very plainly described.

Don't even bother replying unless you tie it to what Krstic writes. Without that, it's just your unsupported attempt at FUD, and totally empty of substance.

finally, children first!

[JasonNolan]

I teach about children and technology, so my statement is not strange, but I've always believed that young learners (if they're going to use digital technology at all, which is a different issue) should have the best. In the old days, you'd see a child with a 256 colour display trying to do something using cassette tapes to load programs while we whizzed away with the best stuff. It seemed strange to provde the developing mind with the most limited set of tools when a business exec who never did much with it anyway and the brightest and shiniest. Of course the child is seen as less valuable. My attitude is, and was before I started teaching about childrean and tech., that you give the best [insert variable] to the children to get the best children, and that the best children lead to the best adults. But we give the worst to children. (I've used best and worst for their vague sense of value without specifics to keep with the notion of the article). I don't know if the OLPC project is the best thing for children, though I've been following the topic for longer than this specific project's been around, but they might as well have the best possible security, since the world does such a poor job of keeping them safe in most other categories.

Re:It's worse than that, it prevents app partition

[Anonymous Coward]

I ated the purple berries.

Re:It's worse than that, it prevents app partition

[micrometer2003]

Programs can communicate but the process should be supervised by the o/s. The very common "buffer overflow" security breach would be impossible when the o/s, in a separate and priveleged part of the machine brokers the exchanges and enforces strict definitions of requests, e.g. size, beginning address, ending address, appropriate authority, duration, initializations, etc. Most desktop systems run programs that have all of the same priveleges as the o/s. Put another way, these o/s's are simply very large user applications running bareback on the processor. It's no wonder that pc security is a joke.

Why Unix Permissions Lasted So Long

[ajs318]

Far be it from me to knock this before I've tried it, and that's not my intention anyway; but there's a reason why unix file permissions have lasted so long, and that is that they're actually quite good for the job they are supposed to do.

Sure, you could have finer grained, ACL-based permissions. But that would be over-complicated for most real-life situations, with the result that they would end up not being used properly -- and that might well make things more dangerous. The idea of dividing the world into "user", "group" and "others" each having separate permissions to read, write and execute (or not) is simple enough for non-security experts to understand, while working well enough most of the time. It's that x bit, and the fact that you have to turn it on by performing some deliberate action, that really makes the difference between unix-based and DOS-based systems.

If you want to limit a user or a process to a particular area of the filesystem and a subset of commands, there's always chroot.

This IS a good thing.

[WarlockD]

We all know that XP is insecure, but how many people would of NEVER installed updates unless automatic updates were turned on? How many bots are out there because people don't bother with simple anti-virus software

The people who are going to use this laptop are NOT even on the level of a Dumb American User (DAU). These are people who will use it for, at best, for e-mail. Any other applications that are installed would HAVE to work and not be corrupting the system. Lets face it, if you lived in a farm in South America for a few generations, its not like your going to acquire the security skills, overnight, to run XP on the web.

Though, my real issue is corruption though. Have they really developed a good system for keeping the signed keys from people who mean harm? What if the local country officials use this whole "lease" idea to threaten a local because he didn't vote right?

No Great Brain, But..

[vmfedor]

I'm certainly an amateur programmer at best, and haven't worked extensively in security, so I don't know if what I'm about to say makes sense. But if I understand this whole thing correctly, basically each program is given a set of things it's allowed to do and is denied access to everything that's not on this list. So, if interoperability is a problem, couldn't he just include an item such as "interaction with program/module X on Such-and-Such File" or something equally restrictive to be a possible item on this list?

Sorry if that made no sense whatsoever.

Totally, totally wrong

[cheros]

The problem is not software or hardware and how you protect it - it's the end user.

You make a choice here: either you enable self management of the system, which opens the potential for socially engineering a user into doing something they shouldn't, or you close the box tightly and thus incur an administration overhead (which would annul the low costs of any OLPC machine) and/or lose the flexibility. The latter may be feasible with OLPC if you made it fixed purpose (i.e. set loadset with no deviation), but that strikes me as defeating the whole concept.

Look at most trojans and virus infections: they rely on the user doing something stupid, and they do so - with gusto. We got a new admin girl and the first thing she did when she got her machine was complain she couldn't install 'her' programs on it. On inspection she would have made the box a botnet zombie as well as a spam relay, all because the programs were 'cute'.

The same is happening with children. There are plenty of sites luring children with games, whilst surreptitiously probing the box for vulnerabilities through which to install malware - or it's made to look like another game so that the child will install it. And thanks to the carelessness in coding most of the "official" kid games, plenty of parents have set the child up with admin rights because the games won't work otherwise. And those are the ones that had at least the idea of creating separate accounts - plenty of machines just go live as administrator with parents and children just using "the computer".

Go ahead, fix the computer, unless you fix/educate the users at the same time you're still losing the battle.

Centralized Storage?

[Anne.O.Neimaus]

At the bottom of http://wiki.laptop.org/go/Bitfrost:

Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the event that the laptop is lost, stolen or destroyed.

Generally, a nice idea - automated backups. However, the overall design (no passwords, etc.) seems to imply that this information will all be stored in the clear. That means the centralized repository can be regularly scanned by any party with access.

Maybe if they added functionality to allow for encrypted directories (or "drives", ala TrueCrypt), and ensured that any virtual-memory/swap-partition was always scrambled with a boot-specific randomized key...