[OLPC Security] Seamless Lessons & Security (commentary)

Jameson "Chema" Quinn jquinn at cs.oberlin.edu
Mon Jul 7 21:06:44 EDT 2008


> In other words, to support Browse launching Pippy when a .py file is
> clicked, Rainbow would have to confer upon Browse the privilege of
> launching other activities (which may, and in the case of execution
> environments such as Pippy and eToys, regularly will) have higher
> privileges than Browse itself, have such launched activities operate
> on arbitrary input provided by Browse, and not require user approval
> anywhere in the process.


Higher privileges in what way? If all we're talking about is P_MIC_CAM, the
problem is only for data flows in the other direction (from Record to
Browse, for instance). That problem, though separate from the current use
case, is real, and I have suggested a mechanism ("private" files which are
not openable by an activity with P_NETWORK) which will prevent the problem
data flow, once Bitfrost is further implemented (and until then, it is not
actually a problem, because there's no security here anyway).


> The way to do it is to throw up a (system-, not Browse- rendered!)
> warning dialog indicating that a security boundary is about to be
> crossed, and allowing the user to stop the action -- unless this
> particular boundary traversal was specifically approved ahead of time.


I agree, this is good enough, precisely because the only* attack this should
allow is temporary DOS (ie, "I didn't mean to open that activity, now I have
to wait until it finishes opening and close it"). Since the consequences are
immediate and visible, it will condition the user to understand what's going
on, not to ignore the dialog.

If there is another attack possible, we will need more than just a dialog
for security. For instance, the private files mentioned above.

Jameson

*secondary spy attacks would be possible if a networked activity makes
stupid or deliberate security mistakes, using settings to corrupt later
instances of the same activity. These attacks would still be limited by the
access of the later instances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080707/9a6b5ae2/attachment.htm 


More information about the Security mailing list