[OLPC Security] Seamless Lessons & Security (commentary)

[Michael Stone]

We need a way to seamlessly integrate supporting materials such as
readings, lesson plans, together with activities. HTML is the way to do
this and the browser is what we use to display html. URI's are what we
use to link to different resources.

A few brief thoughts:

* a _general_ seamless 'launch activities by clicking URLs' facility is
wholly incompatible with Bitfrost in the presence of highly privileged
activities like our 'execution evironments': EToys, Pippy, etc.

* _specialized_ seamless launch facilities can already be built on top
of fixed data, e.g. by adapting the Browse codebase into new (fixed)
Lesson-specific codebases.

* a _general_ "seamful" 'launch activities with operator-chosen
permissions' facility is highly desirable and should be pursued.

Questions?

Michael & Ivan

[Bryan Berry]

seamful approach sounds workable to me

This is a very productive discussion!

-----Original Message-----
From: Michael Stone <michael at laptop.org>
To: Bryan Berry <bryan.berry at gmail.com>
Cc: devel at lists.laptop.org, security at lists.laptop.org
Subject: Seamless Lessons & Security (commentary)
Date: Mon, 7 Jul 2008 00:28:03 -0400


* a _general_ "seamful" 'launch activities with operator-chosen
permissions' facility is highly desirable and should be pursued

[Bert Freudenberg]

Post by Bryan Berry
seamful approach sounds workable to me
This is a very productive discussion!
-----Original Message-----
From: Michael Stone <michael at laptop.org>
To: Bryan Berry <bryan.berry at gmail.com>
Cc: devel at lists.laptop.org, security at lists.laptop.org
Subject: Seamless Lessons & Security (commentary)
Date: Mon, 7 Jul 2008 00:28:03 -0400
* a _general_ "seamful" 'launch activities with operator-chosen
permissions' facility is highly desirable and should be pursued

Well, currently our "seam" is an abyss you have to jump over. But
people are arguing there is no problem (see #6958 "I don't understand
what the issue is. The system already supports this.")

Taking the learner out of context (say, clicking an URL) to a totally
different, information-laden view (the Journal details page) where she
has to remember to click in a specific spot (top right corner icon) is
at best doing the Pavlovian training Bitfrost set out to not let
happen. It can although completely wreck the train of thought.

But a seam does not have to be disruptive.

A better design for this might be to show one of our ubiquitous little
black menu palette with the top entry being "open in <activity>". This
palette would be shown by a trusted party (Sugar shell) at the
position of the mouse pointer so requires explicit user interaction,
but it would still feel in-context, it would not shift focus to a
different screen location etc.

- Bert -

[Bryan Berry]

Martin's solution works for me.

This kind of dialogue is good for OLPC. Substantive and really thinking
about how kids and teachers will use the XO and Sugar.

We intend to embed all the activities relevant to a particular course
into one .xo bundle, excluding the pre-installed mainstays like Scratch
and Squeak. It has to be a super simple process to install an off-line
course, only two steps really.

For example, geometry module for Weeks 1-4 could include 2 flash
animations, two Squeak activities, and a relevant gcompris activity all
in the same .xo bundle. This way the kids and teachers won't have to
hunt down and install different xo bundles to cover a period of lessons.
Many of our kids are absent from school for a few weeks at a time to
work in the fields. We want them to be easily able to collect a period
of schoolwork all in one bundle and do it in the evenings after work.

How would JEB's work if the activities are installed as one .xo bundle?
And does anyone have a better idea?


-----Original Message-----
From: Martin Langhoff <martin.langhoff at gmail.com>
To: Martin Dengler <martin at martindengler.com>
Cc: Ivan Krsti? <krstic at solarsail.hcs.harvard.edu>, Bryan Berry
<bryan.berry at gmail.com>, devel at lists.laptop.org,
security at lists.laptop.org
Subject: Re: Seamless Lessons & Security (commentary)
Date: Mon, 7 Jul 2008 11:54:17 -0300

Loading Image...
...so perhaps I need a different understanding of "launch-by-click" for
executables. Please accept my apologies for wasting your/others time
if I've misunderstood.

I think that the dialogue you captured is the "seam" people are
talking about :-)

In any case, I think this discussion has missed that what Bryan is
requesting is *much* saner from a security POV than downloading
putty.exe (which is as bad as it gets). Bryan wants to be able to
provide links that start existing activities on the XO - a
document-triggered launch (using JEBs) is good enough, and I think it
can be deemed reasonably safe. We trust (and confine) the activities
on the box.

So I don't think there's a major problem here.

cheers,



m

[Bert Freudenberg]

Is that good enough? I think it would work fine for paranoid
security geeks,
but what about school children?

It's good enough because the purpose of the dialog is not to protect,
but to inform.

I respectfully disagree that the dialog/notification can achieve that
goal.

The goal is to prevent an activity from automatically launching
another activity without user interaction. A system-provided dialog or
menu does that just fine.

- Bert -

[Toby Murray]

Post by Bert Freudenberg

Is that good enough? I think it would work fine for paranoid
security geeks,
but what about school children?

It's good enough because the purpose of the dialog is not to protect,
but to inform.

I respectfully disagree that the dialog/notification can achieve that
goal.

The goal is to prevent an activity from automatically launching
another activity without user interaction. A system-provided dialog or
menu does that just fine.

Isn't that like saying that the goal of airport security is to ensure
that noone can board without showing ID.
No it's not. The goal of airport security is to ensure that noone can
board who is deemed unsafe to allow to fly.

Right. But Bitfrost is not about airport security.

No but airport security demonstrates that intelligent people can fall
victim to thinking they're providing security when what they're really
providing is security theatre.

The dialog/notification that Ivan cited above is an example of security
theatre.

Likewise, the goal here is to
1. prevent an activity from automatically launching another unless the
user has designated in some way that they want the other activity
launched
2. ensure that the launched activity is not given any authority that
the user wouldn't expect it to have
#2, like #1, should be inferred from the user's actions.

#2 is handled by Rainbow. #1 is handled by any unspoofable method
requiring explicit user interaction.

It's the form of the user interaction that bothers me. Unless the user's
intent about authority can be inferred from this action, the problem
hasn't been solved. You're just providing security theatre and training
users to click through unintelligible dialogs.

Maybe you should read up on Bitfrost again. Your fancy information
will not get read. In fact, the user might be a kid who cannot read yet.

What fancy information? I'm advocating not providing an
"information"-laden dialog that makes no sense to the user -- whether
they can read or not. I'm advocating the whatever user interaction is
required for the unspoofable method invocation, you better be sure that
it conveys enough information to infer the authority that the user
expects the activity to be granted.

I think we probably agree here and are just talking past each other.

Feel free to forward to the mailing list if you intended this exchange
to be public.

This message is being cc'd to the list. I hadn't realised that the list
doesn't set the reply-to address back to itself rather than the original
sender. My bad.

Cheers

Toby

[Bert Freudenberg]

Post by Toby Murray

Post by Bert Freudenberg

Is that good enough? I think it would work fine for paranoid
security geeks,
but what about school children?

It's good enough because the purpose of the dialog is not to protect,
but to inform.

I respectfully disagree that the dialog/notification can achieve that
goal.

The goal is to prevent an activity from automatically launching
another activity without user interaction. A system-provided dialog or
menu does that just fine.

Isn't that like saying that the goal of airport security is to ensure
that noone can board without showing ID.
No it's not. The goal of airport security is to ensure that noone can
board who is deemed unsafe to allow to fly.

Right. But Bitfrost is not about airport security.

No but airport security demonstrates that intelligent people can fall
victim to thinking they're providing security when what they're really
providing is security theatre.
The dialog/notification that Ivan cited above is an example of
security
theatre.

I don't think this discussion is fruitful without looking at the
actual threat model.

The threat that was discussed is that a malicious activity could
launch other activities on its own, resulting in DOS. The dialog (or
any required user interaction) to me seems adequate to prevent this
attack. Do you disagree?

If you see other threats in this scenario that are not otherwise
addressed by Bitfrost then please be specific about them, and we'll
have a separate discussion.

- Bert -

[Jameson &quot;Chema&quot; Quinn]

Post by Bert Freudenberg
I don't think this discussion is fruitful without looking at the
actual threat model.

I agree absolutely.

Post by Bert Freudenberg
The threat that was discussed is that a malicious activity could
launch other activities on its own, resulting in DOS. The dialog (or
any required user interaction) to me seems adequate to prevent this
attack. Do you disagree?

This is precisely what the dialog is for in my mind, and it is the one case
where a dialog is justified.

If you see other threats in this scenario that are not otherwise

Post by Bert Freudenberg
addressed by Bitfrost then please be specific about them, and we'll
have a separate discussion.

I mentioned another threat which is involved with cross-activity launching,
though is not directly part of the "seamless lessons" use case. This is the
idea that an activity with P_MIC_CAM could automatically launch or pass data
to an activity with P_NETWORK. Nobody has yet given any comment on this
threat or my proposed solution:

*Data from a P_MIC_CAM activity is marked so that it simply cannot be opened
by a P_NETWORK activity.* Specifically, there is a "Private" metadata
attribute for all journal contents. There are two new bitfrost privileges,
P_CREATE_NONPRIVATE and P_READ_PRIVATE. All activities have the ability to
create and read its own private journal entries and to read nonprivate
journal entries it did not create. The new privileges are needed to,
respectively: create nonprivate entries; and read private entries created by
other activities. P_CREATE_NONPRIVATE is similar to (or, possibly,
implemented as synonymous with) P_NETWORK in that it is not granted along
with P_MIC_CAM without user intervention. In the same way, P_READ_PRIVATE is
similar to (or, possibly, implemented as synonymous with) P_NETWORK in that
it is not granted along with P_MIC_CAM without user intervention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080708/e81883fe/attachment.htm

[Jameson &quot;Chema&quot; Quinn]

Oops, there was a typo in the last sentence of my message; the two
privileges should have been exchanged. It should read (changes in bold):

P_CREATE_NONPRIVATE is similar to (or, possibly, implemented as synonymous
with) P_NETWORK in that it is not granted along with P_MIC_CAM without user
intervention. In the same way, P_READ_PRIVATE is similar to (or, possibly,
implemented as synonymous with) *P_MIC_CAM* in that it is not granted along
with *P_NETWORK* without user intervention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080708/53d5e917/attachment-0001.htm

[Frank Ch. Eigler]

Post by Toby Murray
[...]

Isn't that like saying that the goal of airport security is to ensure
that noone can board without showing ID.
No it's not. The goal of airport security is to ensure that noone can
board who is deemed unsafe to allow to fly.

Right. But Bitfrost is not about airport security.

No but airport security demonstrates that intelligent people can fall
victim to thinking they're providing security when what they're really
providing is security theatre.
The dialog/notification that Ivan cited above is an example of security
theatre.

The phrase "security theater" has taken the role of a throwaway
pejorative by overcasual use. Please justify your arguments from
first principles.


- FChE

[reynt0]

On Tue, 8 Jul 2008, Toby Murray wrote:
. . .

Post by Toby Murray
What fancy information? I'm advocating not providing an
"information"-laden dialog that makes no sense to the user -- whether
they can read or not. I'm advocating the whatever user interaction is
required for the unspoofable method invocation, you better be sure that
it conveys enough information to infer the authority that the user
expects the activity to be granted.

. . .

To step back a little from this discussion, FWIW:

Does the basic idea set of OLPC include encouraging generic
"agency" (ie something like an awareness of the possibility
of self-assertiveness) on the p[art of XO users? I think it
does, tho maybe not stated explicitly in those terms? The
opportunity to react to a popup is a primitive opportunity
to practice agency--a popup may be just an offer of a binary
choice set ("yes" or "no") but gives the user an opportunity
of self-expression, albeit a lot more primitive than writing
one's own little prog and showing it to one's friend or
classmates.

Might viewing the popup dialog box issue in this way be
helpful in creating dialog boxes which could be some
approximation to generally--culturally neutral--understandable?
If the users have any intro to the units, the ideas included
in such intro could prepare their minds for being in control
of their units; and dialog boxes then could be, rather than
prompters of the stereotypical power user annoyance or
clueless user synaptic click-through, instead little items
of interest and (ideally) happiness at self-expression. And
also (ideally) recognizable as occasions to behave with the
responsibility I would suppose users likely will be asked
to practice around the units. Kids will have to be expected
to experiment with rules, and might well click "yes" when
they should click "no" {*} just to see what happens, but
with any luck they'd be doing it with awareness.
{*: of course, the understanding I'm suggesting might
result in dialog boxes whose choice sets might involve
values other than "yes" or "no"; that would be part of the
craft of getting the right design}

[Jameson &quot;Chema&quot; Quinn]

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