Re: One Laptop per Child security
On Fri, Feb 09, 2007 at 01:22:06PM +1000, James A. Donald wrote: > Nicolas Williams wrote: > > The text you quote doesn't answer the question; the > > rest of the wiki frontpage says little more. It tends > > to make me think that if an application wants to do > > something that I've not enabled it to do ahead of time > > then it fails. Failure is incovenient. So as near as > > I can tell from the text you quote BitFrost sets its > > convenience/security parameters differently than other > > OSes, but there's nothing truly Earth shatteringly new > > there. > > There is a great deal that is earth shatteringly new, > and it is documented - albeit in rather unclear and non > standard format. > > The fundamental difference is that each application is > run in its own VM, and so *cannot* exercise full user > powers, whereas with *all* other OSs, if your solitaire This is a good summary -- the analogy that I asked for. It doesn't sound so new either though. Labelled OSes and trusted desktops allow as much. My employer makes this stuff (much, if not all of it FOSS), and there have been some very impressive blog posts showing how you can have applications, including browsers, running in different "VMs," with some VMs VPNed into a private network, and some not. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Peter Gutmann wrote: > Just a general thought, it seems like the OLPC security design is a real-world > implementation of Bill Cheswick's "Windows OK" proposal. See for example > http://usablesecurity.com/2005/07/07/bill-cheswick/ for more on this (modulo > the comments on "feature starvation", which don't apply to the OLPC design). The systems are similar in their desire to offer no-frills protection, but I think the similarities end there. If I had been trying to simply lock the machines down, as is the essence of Cheswick's proposal, my task would have been extremely simple. The resulting security model would also have gone against everything OLPC's educational principles stand for. I think you'll find that moving (even mentally) from "protection by not running untrusted code" to "usable protection _while_ running untrusted code" involves a few trips through a labyrinth sitting on top of a mine field, with the exit guarded by a killer rabbit. It's also certainly possible I'm not smart enough, and other people find this to be an easier problem. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Just a general thought, it seems like the OLPC security design is a real-world implementation of Bill Cheswick's "Windows OK" proposal. See for example http://usablesecurity.com/2005/07/07/bill-cheswick/ for more on this (modulo the comments on "feature starvation", which don't apply to the OLPC design). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
-- Simon Josefsson wrote: > Would it be possible for one malicious web site to be > able to access (or even influence) what is being done > in another tab or window of the browser? > > If the user is talking to a bank, then that scenario > may threaten the user's privacy. > > Sandboxing the browser instance for each site would > solve that problem. As designed, hard to VM each browser instance. If one uses something less than VM, one relies on quite a lot of code that one does not really understand being correct. I do not see any alternative to this, short of a major browser rewrite. Ideally, there should be a separate VM responsible for talking to each site, interpreting javascript, etc, which is created when the conversation is started, and shut down when one browses away from that site. Big project. Or instead of VMing things, one could structure the code so that automatic code checks make it impossible to compile code that is bad in certain ways - again a big project. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG txnLOsPeyJqwn5LYEMAdBUQoBArt6OJO8Rp8P6Vn 4GQB25JeUovLVxb1JZBHA6Q0qjCGFQGkhchihumVh - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
-- Nicolas Williams wrote: > The text you quote doesn't answer the question; the > rest of the wiki frontpage says little more. It tends > to make me think that if an application wants to do > something that I've not enabled it to do ahead of time > then it fails. Failure is incovenient. So as near as > I can tell from the text you quote BitFrost sets its > convenience/security parameters differently than other > OSes, but there's nothing truly Earth shatteringly new > there. There is a great deal that is earth shatteringly new, and it is documented - albeit in rather unclear and non standard format. The fundamental difference is that each application is run in its own VM, and so *cannot* exercise full user powers, whereas with *all* other OSs, if your solitaire game is a trojan, or (more likely) has flaws that enable an adversary to get control of it, it can read all your user documents and mail them to the adversary, check your interaction with the browser to detect you typing in passwords to your bank account and share trading account, get the names of everyone on your address list, and spam cons and trojans to them in each others names, use your modem to dial a ten dollar a minute gay S&M sex line in Outer Mongolia, launch a denial of service attack against The Gold Casino as part of an extortion scheme, spray ads onto your screen, make your system a file share server for other people's child pornography, and report all your video files to the copyright lawyers. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG x4p2u5+Go3URK4IvzoJkO/+K0lr4p4XW2aNmlbEi 4dlOW8vAN4GsnWBzDGfvyjQYPosBfDEqrH3rKQ451 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Steven M. Bellovin wrote: > What about unprotected, frequently-running web browsers? I don't follow. How do you hop from one browser to another, if you want to use one as your spread vector? Browsers don't accept inbound connections. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
[Perry -- this is a very interesting discussion, but please feel free to tell us to bugger off to the OLPC security list if you find it too off-topic.] Nicolas Williams wrote: > It tends to make me think that if an > application wants to do something that I've not enabled it to do ahead > of time then it fails. If an application wants to do something for which _it_ didn't request permission ahead of time, it fails. The difficulty is in creating the permission set with the proper mutual exclusions, and in such a way that it's very hard to request a permission set required to do something malicious. At the same time, it has to be easy for most applications to request the permissions they need to get their work done. I've tried to strike a decent balance. > I'm imagining BitFrost as something like OpenBSD's systrace facility + a > small number of well-profiled apps. If this is a good analogy, please > confirm it. Think high-level systrace, with each application providing the policy at install time, and the user being able to amend it at any time. > In a world where web-based applications are all the applications you > need, this attitude towards the browser leaves BitFrost with a big hole > in it. Protecting the browser is not in the scope of _system_ security. I'm working on it separately, and want to see how to make it better, but to the system security platform, a browser is just another application. To that end, if the entire application is compromised, Bitfrost provides very strong assurances about what an attacker can('t) do to the rest of the system. > I think you have to think of each site as a separate application, and > profile that, if I understood BitFrost correctly. No, the platform is too low in the security stack to have any idea about what tabs and sites are. It sees a process, or some number of processes, which are the browser. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
On Thu, 08 Feb 2007 13:03:27 -0800 Ivan Krsti? <[EMAIL PROTECTED]> wrote: > Hi Paul, > > Paul J. Morris wrote: > > If a worm can propagate to every OLPC laptop it must > > have network access in some form, this means it could use the > > entire set of OLPC laptops to perform a distributed denial of > > service attack on a target. > > Sort of. The worm would still be subject to connection rate and > bandwidth throttling, so the laptops are not _that_ useful as a DDoS > launchpad. But it's all a big hypothetical scenario, because finding > invariants to infect across all OLPC systems is likely to prove > extremely difficult; only applications that the user sometimes runs > generally listen on a port and act as a server. There aren't going to > be unprotected, constantly-running servers to exploit. > What about unprotected, frequently-running web browsers? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
On Thu, Feb 08, 2007 at 12:23:40PM -0800, Ivan Krstić wrote: > Hi Nico, > > Nicolas Williams wrote: > > If this means pop-up dialogs for every little thing an application wants > > to do then the result may well be further training users to click 'OK'. > > It really does help to read at least the introduction to the document in > question before hitting 'reply' to an e-mail :) The text you quote doesn't answer the question; the rest of the wiki frontpage says little more. It tends to make me think that if an application wants to do something that I've not enabled it to do ahead of time then it fails. Failure is incovenient. So as near as I can tell from the text you quote BitFrost sets its convenience/security parameters differently than other OSes, but there's nothing truly Earth shatteringly new there. Now, if it's a new OS presumably you start from scratch in terms of applications, so you get to have usable profiles for all of them initially, and maybe _that_ is what is truly new. I'm imagining BitFrost as something like OpenBSD's systrace facility + a small number of well-profiled apps. If this is a good analogy, please confirm it. If it isn't and there is another similarly simple analogy, then tell me what it is -- simple analogies, imprecise though they might be, can help provide a good starting point to understand something new. > > As for browsers, you'd have to make sure that every window/tab/frame is > > treated as a separate application, and even then that probably wouldn't > > be enough. Remember, the browser is a sort of operating system itself > > -- applying policy to it is akin to applying policy to the open-ended > > set of applications that it runs. > > The browser is an environment, which makes it an edge case. Even so, > Bitfrost provides guarantees on what happens if you take over the > browser: it's very hard to violate the user's privacy, you can't harm > the machine in any way, you can't get unauthorized access to the user's > documents. From a systems security point of view, that's all I could > hope for. Security within the browser cannot lie in the scope of the > spec. (Not to say that I don't care about it, though -- I'm meeting with > Mozilla's CSO later today to talk about what we can do to make the > browsing experience more secure.) In a world where web-based applications are all the applications you need, this attitude towards the browser leaves BitFrost with a big hole in it. I think you have to think of each site as a separate application, and profile that, if I understood BitFrost correctly. And that seems unrealistic. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Hi Paul, Paul J. Morris wrote: > If a worm can propagate to every OLPC laptop it must > have network access in some form, this means it could use the entire set > of OLPC laptops to perform a distributed denial of service attack on a > target. Sort of. The worm would still be subject to connection rate and bandwidth throttling, so the laptops are not _that_ useful as a DDoS launchpad. But it's all a big hypothetical scenario, because finding invariants to infect across all OLPC systems is likely to prove extremely difficult; only applications that the user sometimes runs generally listen on a port and act as a server. There aren't going to be unprotected, constantly-running servers to exploit. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
On Friday 09 February 2007 05:42, Nicolas Williams wrote: > On Thu, Feb 08, 2007 at 06:32:44PM +1000, James A. Donald wrote: > > In this OS, instead the > > editor asks trusted code for a file handle, and gets the > > handle to a file chosen by the user, and can modify that > > file and no other. > > If this means pop-up dialogs for every little thing an application wants > to do then the result may well be further training users to click 'OK'. From what I read, the design is quite careful to avoid that issue -- in fact avoiding it is one of the primary design goals. From the user's perspective, what James was describing will work just like any normal application -- the user starts the app, selects "Open File", sees a file chooser dialog, picks the file he/she wants to work on and clicks "Okay". Underneath, what happens is that when the application is started, it sees a file system that contains nothing but the app and its supporting libraries. When the user clicks "Open File", the app requests the service of the OS, which takes care of displaying the file chooser and getting the user's selection. After the user has chosen the file, the OS then maps the file into the app's file system and returns the pathname so the app can open and manipulate it. > The more complex the application, the harder it is for the user to > evaluate all its access requests (if nothing else due to lack of > time/patience). This is true. The OLPC may have an advantage here because its constrained environment (128MB RAM, 512MB persistent storage) will force applications to be simpler, just so they fit. > As for browsers, you'd have to make sure that every window/tab/frame is > treated as a separate application, and even then that probably wouldn't > be enough. Remember, the browser is a sort of operating system itself > -- applying policy to it is akin to applying policy to the open-ended > set of applications that it runs. It might be nice to isolate the tabs, but I think the limitations imposed by Bitfrost on the browser as a whole are sufficient to prevent a large class of attacks. Sorry for continuing this non-crypto discussion, but I think it's a very interesting one. Shawn. pgpGXfrSIwR8c.pgp Description: PGP signature
Re: One Laptop per Child security
Hi Nico, Nicolas Williams wrote: > If this means pop-up dialogs for every little thing an application wants > to do then the result may well be further training users to click 'OK'. It really does help to read at least the introduction to the document in question before hitting 'reply' to an e-mail :) Here are two of the four guiding principles for Bitfrost, stated in the first chapter of the spec: > * No reading required > Security cannot depend upon the user's ability to read a message from the > computer and act in an informed and sensible manner. While disabling a > particular security mechanism may require reading, a machine must be secure > out of the factory if given to a user who cannot yet read. > > * Unobtrusive security > Whenever possible, the security on the machines must be behind the scenes, > making its presence known only through subtle visual or audio cues, and never > getting in the user's way. Whenever in conflict with slight user convenience, > strong unobtrusive security is to take precedence, though utmost care must be > taken to ensure such allowances do not seriously or conspicuously reduce the > usability of the machines. As an example, if a program is found attempting to > violate a security setting, the user will not be prompted to permit the > action; > the action will simply be denied. If the user wishes to grant permission for > such an action, she can do so through the graphical security center > interface. Summary and other principles: http://wiki.laptop.org/go/Bitfrost (borrowed directly from the full spec). > As for browsers, you'd have to make sure that every window/tab/frame is > treated as a separate application, and even then that probably wouldn't > be enough. Remember, the browser is a sort of operating system itself > -- applying policy to it is akin to applying policy to the open-ended > set of applications that it runs. The browser is an environment, which makes it an edge case. Even so, Bitfrost provides guarantees on what happens if you take over the browser: it's very hard to violate the user's privacy, you can't harm the machine in any way, you can't get unauthorized access to the user's documents. From a systems security point of view, that's all I could hope for. Security within the browser cannot lie in the scope of the spec. (Not to say that I don't care about it, though -- I'm meeting with Mozilla's CSO later today to talk about what we can do to make the browsing experience more secure.) Cheers, -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
On Thu, Feb 08, 2007 at 06:32:44PM +1000, James A. Donald wrote: > For many tasks, they have to call upon a small amount of > trusted code. For example the normal way an editor > opens a file is that one gives the editor a file name, > and the editor, having full user authority to read or > change any file in the system, plays nice and opens and > changes *only* that file. In this OS, instead the > editor asks trusted code for a file handle, and gets the > handle to a file chosen by the user, and can modify that > file and no other. If this means pop-up dialogs for every little thing an application wants to do then the result may well be further training users to click 'OK'. The more complex the application, the harder it is for the user to evaluate all its access requests (if nothing else due to lack of time/patience). As for browsers, you'd have to make sure that every window/tab/frame is treated as a separate application, and even then that probably wouldn't be enough. Remember, the browser is a sort of operating system itself -- applying policy to it is akin to applying policy to the open-ended set of applications that it runs. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Hi, Steve. Thanks for your thoughts; comments inline. Steven M. Bellovin wrote: > That firewalls should be omitted is no surprise. A firewall is a > device for centralized policy enforcement; it's useful when policy to > the "outside" -- whatever that is -- is different than policy for > the "inside". If you don't have a well-defined "inside" and > "outside", they're not very useful. The "no firewalls" thing is really a journalistic misrepresentation. There are no *personal* firewalls, in the keep-popping-up-messages-and-prompts sense. P_NET filtering, described in the spec, is implemented exactly by using a firewall -- standard Linux netfilter. Because each program executes in a VM of its own, enforcing network access policies on it becomes very simple: it's a matter of choosing to NAT or not NAT packets from/to its virtual IP, with any applicable restrictions. But it's no longer something the user has to know or care about, which has been one of my fanatical focuses in designing Bitfrost. I firmly believe this is how most security systems should be designed regardless of the target audience, but with 6 year olds in the mix, it's no longer a belief or convenience, it's an absolute necessity. > Even if the crypto authentication succeeds, all it means is that some > process on the other machine has access to the credentials; it says > nothing about whether or not the human in front of that machine wants > to connect. Is this a general comment, or are you talking about some particular crypto authentication on the OLPC? > It would take a fairly radical OS design to > prevent a user-level worm from spreading. Is it really a big deal if a worm spreads to every OLPC laptop, but can't do anything particularly malicious once it's there? > Thought experiment: > explain what OS facilities would have prevented the 1988 Internet > worm from succeeding. If you said "spreading," I'd have a different answer. But let's talk about the worm succeeding. It "succeeded" in bringing down the Internet because it -- accidentally, from what we know -- kept creating running copies even on previously infected machines. Eventually there were too many processes, and the machines buckled under the DoS. The Morris worm amounted to a self-propagating forkbomb. Bitfrost would keep the Morris worm from "succeeding" in any interesting sense. Assuming the worm managed to spread despite the other protections, once it landed on a user's machine and the processes started multiplying, they'd just get throttled back -- to no more than 10% CPU use -- for the combined lot of them -- if the user doesn't have the worm's window in the foreground of the UI. (What window? Exactly.) Decoupling user permissions from process permissions and integrating explicit assent into dealing with the user's documents get you a long, long way towards a usable and reasonably secure system, I think. If I'm wrong, I'll have 10 million reasons to not sleep next year. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
Steven M. Bellovin wrote: > The AV decision is more problematic. While a good > security model can prevent system files from being > overwritten, most worms use purely user-level > abilities. It would take a fairly radical OS design > to prevent a user-level worm from spreading. It is a fairly radical OS design. Programs do not inherit the full authority of the user. They cannot do anything the user can do. For many tasks, they have to call upon a small amount of trusted code. For example the normal way an editor opens a file is that one gives the editor a file name, and the editor, having full user authority to read or change any file in the system, plays nice and opens and changes *only* that file. In this OS, instead the editor asks trusted code for a file handle, and gets the handle to a file chosen by the user, and can modify that file and no other. The nice thing about this OS architecture is that that each executable is loaded and run in its own VM, instead of having access to everything the user has access to. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
On Wed, 7 Feb 2007 15:04:40 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > And here is the wired coverage of the BitFrost platform: > > http://www.wired.com/news/technology/0,72669-0.html?tw=wn_culture_1 > > >From the article: > But it should come as no surprise -- given how thoroughly the project > has rewritten the conventions of what a laptop should be -- that the > OLPC's security isn't built on firewalls and anti-virus software. > > Instead, the XO will premiere a security system that takes a radical > approach to computer protection. For starters, it does away with the > ubiquitous security prompts so familiar to users of Windows and > anti-virus software, said Ivan Krstic, a young security guru on break > from Harvard, who's in charge of security for the XO. > > "How can you expect a 6-year old to make a sensible decision when > 40-year olds can't?" Krstic asked, in a session at the 2007 RSA > Conference. Those boxes simply train users to check "yes," he argued. > > Krstic's system, known as the BitFrost platformRead more at: > http://www.wired.com/news/technology/0,72669-0.html?tw=wn_culture_1 > We're digressing to general security topics here, but I'll take a chance that our moderator will allow this through -- I do mention "crypto"... That firewalls should be omitted is no surprise. A firewall is a device for centralized policy enforcement; it's useful when policy to the "outside" -- whatever that is -- is different than policy for the "inside". If you don't have a well-defined "inside" and "outside", they're not very useful. However, their primary benefit comes from keeping the bad guys away from buggy code. That problem, I predict, will afflict this project as well -- just because a service uses cryptographic authentication doesn't make it immune to bugs, including bugs before the crypto authentication has succeeded. Even if the crypto authentication succeeds, all it means is that some process on the other machine has access to the credentials; it says nothing about whether or not the human in front of that machine wants to connect. The AV decision is more problematic. While a good security model can prevent system files from being overwritten, most worms use purely user-level abilities. It would take a fairly radical OS design to prevent a user-level worm from spreading. (Thought experiment: explain what OS facilities would have prevented the 1988 Internet worm from succeeding. My conclusion, way back when, that nothing in, say, the Orange Book would have stopped it was a major step in my evolution as a security researcher. It can be done, I suspect, but only by very stringent restrictions on application privileges. Have you designed such restrictions? Now assume it's a dual-mode worm, that attacks web servers and web browsers.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: One Laptop per Child security
And here is the wired coverage of the BitFrost platform: http://www.wired.com/news/technology/0,72669-0.html?tw=wn_culture_1 From the article: But it should come as no surprise -- given how thoroughly the project has rewritten the conventions of what a laptop should be -- that the OLPC's security isn't built on firewalls and anti-virus software. Instead, the XO will premiere a security system that takes a radical approach to computer protection. For starters, it does away with the ubiquitous security prompts so familiar to users of Windows and anti-virus software, said Ivan Krstic, a young security guru on break from Harvard, who's in charge of security for the XO. "How can you expect a 6-year old to make a sensible decision when 40-year olds can't?" Krstic asked, in a session at the 2007 RSA Conference. Those boxes simply train users to check "yes," he argued. Krstic's system, known as the BitFrost platformRead more at: http://www.wired.com/news/technology/0,72669-0.html?tw=wn_culture_1 saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
One Laptop per Child security
Earlier today, I publicly released the architecture-level specification for Bitfrost, the security platform on the One Laptop per Child machines: http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt This is a complete but non-technical spec, with its technical complement scheduled for release sometime in late March (there's a pile of crypto powering various choice bits of the system). Comments are very much invited. Cheers, -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]