[cap-talk] BitFrost : OLPC Security Architecture

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Fri Feb 9 14:48:55 CST 2007


David Hopwood wrote:
> 
> 420 The critical observation here is not that Solitaire should never have the
> 421 ability to do any of the above (which it clearly shouldn't), but that its
> 422 creators _know_ it should never do any of the above. It follows that if the
> 423 system implemented a facility for Solitaire to indicate this at installation
> 424 time, Solitaire could irreversibly shed various privileges the moment it's
> 425 installed, which severely limits or simply destroys its usefulness to an
> 426 attacker were it taken over.
> 
> The general approach here is reasonable -- in fact similar to suggestions made
> on this list recently -- the motivation is just poorly explained (and it's not
> clear whether or not the author really understands it).
> 
> 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.

And incidentally, it does have benefit even for malware. If the user grants
authority A to malware package P, and authority B to malware package Q, but does
not give P authority to communicate with Q, then package P should not be able to
get authority that is in B but not A.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>



More information about the cap-talk mailing list