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

[Mike C. Fletcher]

reynt0 wrote:
> 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.
...
>>    http://wiki.laptop.org/go/Developers/Issues#Security
...
> [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".
> 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

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com