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
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
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 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 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 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 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]
interesting and thought provoking resources on quantum crypto
i have been tasked by my advisor to create series of mini-lectures slides on the topic of cryptography for a freshman year CS class. each mini-lecture will be 10-12 mins and will be delivered towards the end of the class (so i will have to make them *very* interesting). There is be 12 sessions. I know what to include in the slides, but i would like to end each session with a link/URL to a interesting and thought provoking resource on quantum crypto. any thoughts? the resource has to be related to quantum crypto saqib http://www.full-disk-encryption.net - 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
[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]
