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=b
lob;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ć <krsticsolarsail.hcs.harvard.edu> | GPG:
0x147C722D

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

And here is the wired coverage of the BitFrost platform:

http://www.wir
ed.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 platform....Read more
at:
http://www.wir
ed.com/news/technology/0,72669-0.html?tw=wn_culture_1

saqib
http://www.full-d
isk-encryption.net

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Wed, 7 Feb 2007 15:04:40 -0800
"Saqib Ali" <docbook.xmlgmail.com> wrote:

> And here is the wired coverage of the BitFrost
platform:
> 
> http://www.wir
ed.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 platform....Read
more at:
> http://www.wir
ed.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.columbi
a.edu/~smb

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

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

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ć <krsticsolarsail.hcs.harvard.edu> | GPG:
0x147C722D

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

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.

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

On Thu, 08 Feb 2007 13:03:27 -0800
Ivan Krsti? <krsticsolarsail.hcs.harvard.edu> 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.columbi
a.edu/~smb

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

[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ć <krsticsolarsail.hcs.harvard.edu> | GPG:
0x147C722D

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

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