Forgot your password?
typodupeerror
Security IT

One Laptop Per Child Security Spec Released 253

Posted by ScuttleMonkey
from the no-school-like-the-old-school dept.
juwiley writes "The One Laptop Per Child project has released information about its advanced security platform called Bitfrost. Could children with a $100 laptop end up with a better security infrastructure than executives using $5000 laptops powered by Vista? 'What's deeply troubling — almost unbelievable — about [Unix style permissions] is that they've remained virtually the only real control mechanism that a user has over her personal documents today...In 1971, this might have been acceptable...We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market.'"
This discussion has been archived. No new comments can be posted.

One Laptop Per Child Security Spec Released

Comments Filter:
  • by filesiteguy (695431) <kai@perfectreign.com> on Wednesday February 07, 2007 @05:46PM (#17927264) Homepage
    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: (Score:3, Funny)

      Please call it: Dynamic Methods Communication Application
    • by Morgaine (4316) on Wednesday February 07, 2007 @07:23PM (#17928452)
      >> 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.
      • I don't think so (Score:3, Insightful)

        by Wesley Felter (138342)
        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
        • by Joce640k (829181) on Thursday February 08, 2007 @03:42AM (#17931942) Homepage
          "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.

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

      • by schwaang (667808) on Wednesday February 07, 2007 @09:32PM (#17929540)

        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 (Score:3, Insightful)

        by r00t (33219)
        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
  • I don't know if this is a good idea or an awesome idea.
    • jail is a hack (Score:3, Informative)

      by DrSkwid (118965)
      http://plan9.bell-labs.com/magic/man2html/2/fork [bell-labs.com]

      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.

    • by TheSHAD0W (258774)
      Whichever it is, it's definitely DRASTIC.
  • 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

    • by abigor (540274)
      "What's the essential difference between Unix style permissions and other permission systems?"

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

        Anyone else?
        • It isn't about ACLs. (Score:5, Interesting)

          by jhantin (252660) on Wednesday February 07, 2007 @06:52PM (#17928146)

          It's the sandboxing. A program run by a given user doesn't automatically get the user's full permissions -- it only gets a small subset. For example, it can't open files from the user's home directory other than by calling a trusted system File Open dialog, which allows the user to select the file and returns an open file handle to the application (or in OLPC's case hardlinks the file into the chroot jail).

          In terms of research projects, see the secure scripting language E [erights.org] and the proof of concept CapDesk [combex.com].

          Interestingly, in the commercial world it only seems to turn up in safe bytecode runtimes -- there's very little out there for native code. For an example of something similar in concept look at JNLP [sun.com] or ClickOnce [microsoft.com] deployers.

      • Re: (Score:2, Informative)

        by AuMatar (183847)
        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.
    • by pla (258480) on Wednesday February 07, 2007 @06:28PM (#17927814) Journal
      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"?
      • 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 c
        • 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.

          • 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 use
      • 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.
      • Re: (Score:3, Informative)

        by stubear (130454)
        "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
        • by Michael Woodhams (112247) on Wednesday February 07, 2007 @08:14PM (#17928936) Journal
          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: (Score:3, Interesting)

          by pla (258480)
          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 corpo
      • Re: (Score:3, Informative)

        by zollman (697)
        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
      • Re: (Score:3, Interesting)

        by a.d.trick (894813)
        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.
    • by dbIII (701233)

      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

    • by Goaway (82658)
      I wonder if the author's used chmod, chown, etc.?

      Obviously not. You are so much smarter than them.
  • by TinBromide (921574) on Wednesday February 07, 2007 @05:49PM (#17927320)
    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: (Score:3, Insightful)

      by supabeast! (84658)
      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.
  • Drastic? (Score:4, Insightful)

    by geomon (78680) on Wednesday February 07, 2007 @05:50PM (#17927322) Homepage Journal
    "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: (Score:3, Insightful)

      by kabocox (199019)
      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, an
      • by Tom (822)

        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.

        • by monkeydo (173558)
          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.
        • by r00t (33219)
          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 milit
    • Re:Drastic? (Score:4, Insightful)

      by Harmonious Botch (921977) on Wednesday February 07, 2007 @06:08PM (#17927598) Homepage Journal
      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? (Score:4, Funny)

        by AuMatar (183847) on Wednesday February 07, 2007 @06:29PM (#17927832)
        There already is, minus the cover. Its marked "Power". You can add the cover via a case mod.
      • Re: (Score:3, Insightful)

        by 4e617474 (945414)

        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 wh
        • by vadim_t (324782)

          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.
  • At the moment every other OS has better security than Windows, what's new?
  • This would indeed be a nice step forward in security if they manage to complete all their principles and goals. It would be nice to have a system that I can hand out to users (or famliy members) that is basically secure out of the box but with a little reading and changing of settings I can obtain full control over. The idea that it would be open is certainly a nice boost to credibility and would, if successful, push all security forward and not just their own.
  • Sand dunes (Score:4, Insightful)

    by Space cowboy (13680) * on Wednesday February 07, 2007 @05:55PM (#17927426) Journal
    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

    • by dave562 (969951)
      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 th

    • by Qzukk (229616)
      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.
      • by jonbryce (703250)
        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.
    • 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 (Score:5, Informative)

      by Edward Kmett (123105) on Wednesday February 07, 2007 @06:58PM (#17928212) Homepage
      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.
  • More Power to Em (Score:3, Insightful)

    by 99BottlesOfBeerInMyF (813746) on Wednesday February 07, 2007 @06:00PM (#17927472)

    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 (Score:4, Informative)

      by Tom (822) on Wednesday February 07, 2007 @06:16PM (#17927692) Homepage Journal
      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...
  • Even worse (Score:2, Interesting)

    by imipak (254310)
    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 a

    • by vadim_t (324782)
      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
      • Re: (Score:3, Insightful)

        by imemyself (757318)
        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
        • by djcapelis (587616) *
          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 suc
          • Re: (Score:3, Informative)

            by rtechie (244489)
            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 thi
            • Re: (Score:3, Interesting)

              by Mad Merlin (837387)

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

    • Re: (Score:2, Informative)

      by patchvonbraun (837509)
      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 t
      • 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.

  • very sceptical (Score:5, Insightful)

    by Tom (822) on Wednesday February 07, 2007 @06:07PM (#17927580) Homepage Journal
    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.
    • Ain't this the truth.
    • Re:very sceptical (Score:5, Insightful)

      by swillden (191260) <shawn-ds@willden.org> on Wednesday February 07, 2007 @08:38PM (#17929124) Homepage Journal

      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.

  • by gd23ka (324741) on Wednesday February 07, 2007 @06:08PM (#17927596) Homepage
    --"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.
    • 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 stol
  • 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.
  • by SilentMobius (10171) on Wednesday February 07, 2007 @06:24PM (#17927788)
    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?
    • Who would love this feature.

       
    • by mypalmike (454265)
      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.
    • 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 tak
    • Re: (Score:3, Insightful)

      by kelnos (564113)
      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 com

  • by Animats (122034) on Wednesday February 07, 2007 @06:34PM (#17927900) Homepage

    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.

    • by fwr (69372) on Wednesday February 07, 2007 @08:05PM (#17928862)
      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.
      • by swillden (191260) <shawn-ds@willden.org> on Wednesday February 07, 2007 @08:56PM (#17929238) Homepage Journal

        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: (Score:3, Insightful)

          by fwr (69372)

          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

          • 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
  • by 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
  • Two Cents (Score:4, Insightful)

    by kahrytan (913147) on Wednesday February 07, 2007 @07:07PM (#17928300)

    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.
  • by rnturn (11092) on Wednesday February 07, 2007 @07:38PM (#17928584)

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

  • by LuckyStarr (12445) on Wednesday February 07, 2007 @08:13PM (#17928926)
    Wow, I read the whole FA. I must be new here.

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

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

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

  • Who holds the keys? (Score:3, Interesting)

    by Louis Guerin (728805) <guerin&gmx,net> on Wednesday February 07, 2007 @09:19PM (#17929442)
    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

There are never any bugs you haven't found yet.

Working...