[cap-talk] some bitfrost answers

[Ivan Krstić]

Hi, all. I caught some interesting thoughts here about OLPC security,
and wanted to reply to a few statements.

Marc D. Stiegler wrote:
> In mid-December this was corrected, the front [OLPC wiki] security 
> page is now filled with philosophy about security goals. There is a 
> shortage of concrete proposals to achieve those goals

Though it wasn't yet released when Marc wrote his message, the Bitfrost
spec should be seen as a very concrete proposal to address our goals. It
does not, however, contain implementation details; this is
intentional, and an implementation-oriented spec will follow in late March.

In another message, Marc wrote:
> The indication that someone involved has seen and remembered at least
>  some portion of our stock presentation is this passage, oddly placed
>  in software installation [...] Hmmm....the solitaire program as an 
> example of limited authority requirements...hmmmm

Sorry to disappoint here -- I've been using the Solitaire example since
October 2000 when I came up with it on the spot in response to a student
question in a CS class. To be fair, I always used to say Minesweeper,
but was told in recent months by several people that Solitaire is more
well-known as the typical Windows game, so I started saying Solitaire.

Marc continues:
> There are nonetheless things that make me despair, as the preface to
>  the solitaire example [...] Well, in fact, the difference is barely
>  interesting, despite the discussion that follows the above excerpt,
>  which is an interesting narrative in which all the words make sense
>  but, for me at least, the sentences do not.

I'd really like the document to read well, so I'm happy to see any ideas
about rephrasing or rewriting parts for clarity. That said, I find the
difference between the two kinds of software very interesting, just not
at the technical level. More below. And don't despair so easily. It's
bad for your nerves :)

David Hopwood chimed in about this difference:
> The value of a) protecting the integrity of software (making it 
> read-only and cryptographically authenticated); b) giving it no more 
> authority than it asked for; does not depend on any particular piece 
> of software being benign. a) and b) can and should be done for all 
> software, regardless of how benign or malicious it is. It doesn't 
> matter (even if it doesn't have any benefit) that we do a) and b) 
> also for malware. This is important since the system *doesn't know* 
> which software is benign and which is malicious -- not even when it 
> is cryptographically authenticated.

Let me explain what I was getting at.

Bitfrost lets software request whatever permissions they want at install
time, modulo some exclusions that make it hard to request a set that
lets you be directly malicious. At the technical level, because you
can't assume that all software will be benign, it doesn't make any
difference that some is, so I could have designed Bitfrost to have no
permission request model whatsoever: applications could just start with
all the permissions, minus the ones they can't have because of the
exclusions. You could say that the system would be no less secure this way.

One level up from the technical side of things, if you assume that most
software people install is in fact benign (which I firmly believe on
intuition and from observation, but can't claim authoritatively since
there's no data), then a system which provides a fine-grained
requestable permission model is going to be pointedly /more/ secure,
because most software will cooperate and shed many privileges it would
normally have. This moves such software from "can do a bunch of stuff,
but can't directly hurt the machine or user" to "almost useless if taken
over" with no adverse impact on the program itself. I certainly find
this to be important. If much of the software being installed wasn't
benign, bothering with fine-grained requestable permission approach
would be sort of pointless.

Cheers,

-- 
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D