[OLPC Security] Terminals

[Jameson "Chema" Quinn]

2008/8/1 Eben Eliason <eben.eliason at gmail.com>

>
>
> On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore <gnu at toad.com> wrote:
>
>> > Why does it matter that you cannot adjust the screen brightness from
>> > the console using the special keys? You can adjust it from Sugar
>> > without root access. The idea was to understand what limits we'd face
>> > using the console for root access instead of a special terminal
>> > activity. What are the Sugar/X Window actions that require root
>> > access?
>>
>> "It doesn't matter if you have to abandon Sugar to do system
>> administration or to recover from a problem?"  Walter, I'm shocked; I
>> would've expected you to be arguing on the other side: "Sugar should
>> be the preferred environment."  That we shouldn't be kicking people
>> out of Sugar, particularly when their system is fragile and in need of
>> diagnosis, repair, or upgrade.  We should keep them in the environment
>> they know and understand, where the Frame works, the controls work,
>> the tabs work the same way, the keyboard keys all do the same things.
>>
>> It was hard for the Support Gang to explain to people how to become
>> root so they could diagnose or fix something they reported as a
>> problem (like a full filesystem, a USB key that didn't work, ...).
>> OLPC was also changing the way you become root (su versus sudo) in
>> different software releases, based on Fedora changes.  We hashed all
>> this out in January, and the Terminal got a new "#" button at the top,
>> which injects the right command to make you root.  There's no such
>> button in the console.  If we push people back to the console, the
>> support load increases.  It's easier to get them to run the Terminal
>> applic...uh, activity, and press the root button, and type this
>> command.  Also, in Terminal, cut and paste works to send us back
>> diagnostic results via Browse.
>>
>> The owners of free software based machines also need the ability to
>> inspect and revise the free software in those machines -- or it isn't
>> free as in freedom.  Legally, OLPC can push that ability out to the
>> very corners of the system (e.g. "You can't do that in Sugar.").  But
>> morally and philosophically, we ought to be pulling it right into the
>> heart of the system ("Of course you can, and it's so easy; here, let
>> me show you!").
>>
>
> I agree with everything said above.
>
>>
>> Let's not lose sight of what's going on here.  The whole reason we are
>> having this discussion at all is because of OLPC's "security" model
>> (Bitfrost).  If the security model doesn't permit integrated,
>> interactive root access that lets people diagnose, repair,
>> investigate, and alter their systems, there's something wrong with the
>> security model -- not something wrong with root access.
>>
>
> And I wonder if it could really be so simple.  Is it possible that we could
> simply have a P_ROOT permission as well, or does that blow Bitfrost out of
> the water?  In a way I'd hope not, since the whole point is that the desire
> for root is requested/advertised, and therefore can (eventually) be denied;
> P_ROOT clearly wouldn't be granted  within the default permissions either,
> once we have them.
>
>
Coincidentally, I have a patch which does just that! See my thread on sugar at ...
OK, I guess I should copy it to devel@ and security@ while I'm at it.

I write this assuming that this might not help matters at all...it could be
> too lenient.  But perhaps we could offer the P_ROOT only to activities which
> a) request it and b) are signed by some signing authority (could be us,
> could be a country, etc.), where the security section of the control panel
> offers a place to designate trusted signing authorities.  I'm no security
> guru, though, which I willingly admit!  Is anything I've mentioned worth
> even considering?
>

Once we have activity signatures, we can talk about this more concretely. I
expect that, for general bitfrost permissions, there will be a bitfrost
control panel that allows you to grant certain permissions to a specific
(hashed version of an) activity; or to delegate the power to grant certain
permissions to other signers (such as the author of an activity, so that
updates get same permissions). I think that it is reasonable to put
additional restrictions on the P_ROOT permission: perhaps it can ONLY be
granted to activities installed at build time OR signed by current XO?
(Then, to change the version of your terminal, you'd either have to do a
full update to a new build, or touch the new version of terminal activity
with Develop to "make it yours").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080801/6028a712/attachment.htm