Terminals

[Eben Eliason]

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.

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?

Clearly it's not "as secure", and there are ways that someone can instruct a
kid to go to the CP, enter a new authority, install an evil app, etc.  But
There's a tradeoff here much like the memory/speed tradeoff we battle with
every day we hack at code...you can only improve some algorithms so much,
and beyond that you have to choose what to optimize for.

- Eben


>
>        John
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080801/1b3e42f6/attachment.html>