One Laptop per Child security

[Shawn Willden]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20070209/646193da/attachment.pgp>