[OLPC Security] Please review the Security section in the Developer's Handbook

[Mike C. Fletcher]

I've been working through roughing out a proper Developer's Handbook and
am now to the Security section. There's a bit of text up there now, but
there's a lot of stuff I just haven't used in the security system at a
practical level (e.g. how do protection bits get declared, how does
signing happen, how do the network filtering filters get declared).

The section is here:
http://wiki.laptop.org/go/Developers/Issues#Security

What I'm looking for on this page is a discussion suitable to be read as
"background issues", not a complete manual (though obviously we'll need
that eventually). This page comes "before" the developer has even
chosen a project, its intended to advise them of restrictions before
they decide *what* they want to build. That is, we want a general
description of the signing process, not a blow-by-blow (that should be
on a linked page). If signing is going to take 2 weeks and involve lots
of legal declarations, trips to some specific geographic locale,
etceteras, that should be on the issues page, while the actual "type
this command" stuff should be on a linked page.

Thanks for any input,
Mike

[reynt0]

I am a new lurker on this list, as I am learning about the
nice OLPC. I have some suggested edits, but as a newbie
do not want just to jump into the wiki, so I am posting
them here to the list, for you folks to use or not as you
wish.

My suggestions follow the snipped quote of MCF.

Cheers.

On Wed, 19 Dec 2007, Mike C. Fletcher wrote:
. . .

Post by Mike C. Fletcher
http://wiki.laptop.org/go/Developers/Issues#Security

. . .

**********Suggestions*****************************:

1. [1st paragraph of "Security" section presently is:]

Your activities will have to work within the OLPC Bitfrost security
system. Bitfrost is a rather intrusive approach to security from the
developer's perspective (while to the user it is quite transparent). This
is by design. To work within Bitfrost you will often need to consider the
security ramifications of what you are doing.

[Suggested revision replaces "activities" which can be equivocal, and
structures the second sentence in a simpler linear form which may be
clearer:]

Your code product will have to work within the OLPC Bitfrost security
system. While to the user it is quite transparent, from the developer's
perspective Bitfrost is a rather intrusive approach to security. This is
by design. To work within Bitfrost you will often need to consider the
security ramifications of what you are doing.


2. [Within the "Restriction Summary" section presently is the line:]

constrain all file-writing to the ${SUGAR_ACTIVITY_ROOT}

[I am not familiar with the system, so I cannot suggest a revision.
But I think it is worth mentioning that "constrain" is used by people
sometimes in ways which actually have opposite meaning, and it is good
always to be explicit what is meant. Here, is it meant that (i) all
file-writing is constrained to be *only* to the ${SUGAR_ACTIVITY_ROOT},
or that (ii) all file-writing is constrained *not ever* to be to the
${SUGAR_ACTIVITY_ROOT}? Since it says "ROOT", I guess (ii), which
would make a suggested revision be "constrain all file-writing so
it never is to the ${SUGAR_ACTIVITY_ROOT}", but I do not know.]

[Mike C. Fletcher]

Post by reynt0
I am a new lurker on this list, as I am learning about the
nice OLPC. I have some suggested edits, but as a newbie
do not want just to jump into the wiki, so I am posting
them here to the list, for you folks to use or not as you
wish.

All of the Developer's Manual is "watched", so that I wind up reviewing
all changes to it, please feel free to fix things which are broken. I
can always revise anything which needs further tweaking.
...

Post by reynt0

Post by Mike C. Fletcher
http://wiki.laptop.org/go/Developers/Issues#Security

...

Post by reynt0
[Suggested revision replaces "activities" which can be equivocal, and
structures the second sentence in a simpler linear form which may be
clearer:]
Your code product will have to work within the OLPC Bitfrost security
system. While to the user it is quite transparent, from the
developer's perspective Bitfrost is a rather intrusive approach to
security. This is by design. To work within Bitfrost you will often
need to consider the security ramifications of what you are doing.

Activities has a specific meaning within the OLPC framework. It is
explicitly a GUI "Application" which is managed as a separately
constrained entity by Bitfrost's security mechanisms. However, you are
correct that the word seems equivocal, and in fact it doesn't cover the
range of possible things a software developer might be creating (e.g.
libraries). I've updated to "code" instead, as most OLPC developers
don't, AFAIK think in terms of "code products".

Post by reynt0
2. [Within the "Restriction Summary" section presently is the line:]
constrain all file-writing to the ${SUGAR_ACTIVITY_ROOT}
[I am not familiar with the system, so I cannot suggest a revision.
But I think it is worth mentioning that "constrain" is used by people
sometimes in ways which actually have opposite meaning, and it is good
always to be explicit what is meant. Here, is it meant that (i) all
file-writing is constrained to be *only* to the ${SUGAR_ACTIVITY_ROOT},
or that (ii) all file-writing is constrained *not ever* to be to the
${SUGAR_ACTIVITY_ROOT}? Since it says "ROOT", I guess (ii), which
would make a suggested revision be "constrain all file-writing so
it never is to the ${SUGAR_ACTIVITY_ROOT}", but I do not know.]

Completely missed the ambiguity there! Obviously read the spec a few
too many times. It's actually the first sense, i.e. you are only
allowed to write to that particular directory. I've used your text
directly for that sense, and then added a bit to explain what the
variable is that's being referenced.

Thanks so much for your review,
Mike

[Morgan Collett]

Post by Mike C. Fletcher
I've been working through roughing out a proper Developer's Handbook and
am now to the Security section. There's a bit of text up there now, but
there's a lot of stuff I just haven't used in the security system at a
practical level (e.g. how do protection bits get declared, how does
signing happen, how do the network filtering filters get declared).
http://wiki.laptop.org/go/Developers/Issues#Security

I think you should mention Rainbow, and the fact that (with exceptions)
activities cannot launch other activities, see them on disk or interact with
them while running.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080102/ae34ab92/attachment.htm