Terminals

[Michael Stone]

On Fri, Aug 01, 2008 at 07:32:11PM -0400, Benjamin M. Schwartz wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Eben Eliason wrote:
>| Is it possible that we could
>| simply have a P_ROOT permission as well, or does that blow Bitfrost out of
>| the water?

1. According to my reading of

  http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l442

Bitfrost is not compatible with a P_ROOT permission.

2. Direct manipulations of the trusted code base by the distribution
chain are also supported:

  http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l450

3. I believe that the existing 'olpc-update', 'yum+gpg', and
'olpc-configure+rpms' mechanisms already satisfy the demands of (2).

>We need an _interface_ that allows users to specify which Activities can run
>with which permissions.

Correct.

>To build that, we need Rainbow to support different running different
>Activities with different permissions.

Rainbow has supported placing activities into different groups based on
the contents of a 'permissions.info' file for months. See commit
58c164f2 which shipped in rainbow-0.7.11 on March 25, 2008. (The work
leading up to that commit was actually available in commit bd26557f from
November 13, 2007 but was not merged until March because of various
"code freezes" that lasted somewhat longer than they should.)

As you can see, the present security difficulties stem from the lack of
effort spent on recording user intentions about what permissions should
be applied to what activities. Signatures do absolutely nothing to
address this problem -- they only permit an as-yet undesigned system
interpreter to check whether the authors W of claim X about blob Y knew
secret Z. These assertions yield no new power because the Bitfrost
security model asserts that trusting that author W wrote blob Y implies
no trust in blob Y itself. It's a good reason to display hints about
blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author
W, but it is _NOT_ sufficient to grant Y permissions in the initial
default-deny configuration proposed by Bitfrost.

It is probably appropriate, here,  to reiterate my third claim above --
namely, that deployment-team's desire to add code directly to the TCB is
_already covered_ by other mechanisms unrelated to activity installation.

>To build that, we need Activities to be identified by a unique secure
>token. To build that, we need a new bundle format.

No new bundle format is needed to track activities according to
non-spoofable tokens. All that is needed is to teach the software making
authorization decisions (Sugar) to use the correct token.

Regards,

Michael