2008/8/1 Eben Eliason <[EMAIL PROTECTED]> > > > On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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").
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel