Re: [IAEP] [Sugar-devel] A security vs. functionality question
Could you let the invited user in a chroot by default and only allow full access if the inviting user explicitly allows it? 2009/8/6 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Gary C Martin wrote: How are two (or more!) remote individuals expected to co-operate and share the same command line and not mess up? 1. Out of band. 1a. That can mean, for example, a pre-existing understanding of the purpose of the session. If it's an expert connecting to perform an operation, then you've already agreed about who's going to be doing most of the typing. 1b. Via a live chat. That can be as simple as a Chat activity instance. Eventually, I am counting on overlay chat [1] and push-to-talk [2] to solve the out of band communication problems. 2. Multiple windows ShareTerm is built on GNU Screen, which supports multiple independent windows not unlike what you describe. (It sometimes calls itself a text only window manager.) In pair programming, for example, users could type in separate buffers, looking over each other's shoulders periodically. [1] http://dev.laptop.org/attachment/ticket/3310/activity_chat_sketch.png [2] http://wiki.laptop.org/go/Push_to_Talk ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A security vs. functionality question
Lucian Branescu wrote: Could you let the invited user in a chroot by default and only allow full access if the inviting user explicitly allows it? 1. What sort of interface do you have in mind? What is more explicit than Share with: My Neighborhood? 2. Why a chroot, and not Rainbow? 3. How do we create a chroot without requiring root privileges? (It seems many Sugar users, such as those in Uruguay or on LTSP, will not have root.) --Ben signature.asc Description: OpenPGP digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A security vs. functionality question
Share with: My Neighborhood is too broad to allow full access. But Share with: John should be enough to assume that you trust John. Or instead have a separate option Share with: John (full acces). A chroot because afaik rainbow doesn't really work outside the XO distro My impression may be wrong, though. I had assumed everyone has root access, it is such a basic need for a machine you own. 2009/8/7 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: Could you let the invited user in a chroot by default and only allow full access if the inviting user explicitly allows it? 1. What sort of interface do you have in mind? What is more explicit than Share with: My Neighborhood? 2. Why a chroot, and not Rainbow? 3. How do we create a chroot without requiring root privileges? (It seems many Sugar users, such as those in Uruguay or on LTSP, will not have root.) --Ben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A security vs. functionality question
Lucian Branescu wrote: Share with: My Neighborhood is too broad to allow full access. But Share with: John should be enough to assume that you trust John. Or instead have a separate option Share with: John (full acces). Sugar does support direct Invitations for private sharing. I like the idea that full permissions would be retained if shared by invitation only, but that permissions would have to be dropped before any public sharing. This might be possible to implement in current systems. A chroot because afaik rainbow doesn't really work outside the XO distro My impression may be wrong, though. Rainbow is not currently used much outside of the XO, but it should be, and it can be. Michael Stone, who developed it, no longer works for OLPC, but he has continued to update it. It can be packaged for any distro. There has been some bitrot; Sugar needs to be tweaked to regain compatibility. Someone will have to be bold enough to write the patches. I had assumed everyone has root access, it is such a basic need for a machine you own. Not all Sugar users run on machines that they own. Some are students running on school computers. Some are children who run on their parents' computers. In any case, I'm uncomfortable with an Activity requiring arbitrary root access, and what Rainbow provides is very much like a chroot (chhome? chuser?). --Ben signature.asc Description: OpenPGP digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A security vs. functionality question
Lucian, Ben: Here are a bunch of reactions. Apologies for the delay. :) Michael Lucian Branescu wrote: A chroot because afaik rainbow doesn't really work outside the XO distro My impression may be wrong, though. Would you mind taking a look at http://wiki.laptop.org/go/Rainbow for me and letting me know what questions you are left with? Ben Schwartz wrote: Rainbow is not currently used much outside of the XO, but it should be, and it can be. Michael Stone, who developed it, no longer works for OLPC, but he has continued to update it. It can be packaged for any distro. There has been some bitrot; Sugar needs to be tweaked to regain compatibility. Someone will have to be bold enough to write the patches. Sascha and I actually wrote the most important patches several months ago and Tomeu merged them last weekend in response to #593. (Thanks, Tomeu and Sascha!) (That being said, there's more fun to be had -- check out the next steps Rainbow page!) Lucian Branescu wrote: I had assumed everyone has root access, it is such a basic need for a machine you own. The most notable existing Sugar users I know of who lack easy root access are the kids using Sugar in Uruguay and Ethiopia. It's an unfortunate situation. Ben Schwartz wrote: To educators: How concerned are you about a feature that allows one student to invite others to play on their computer? Remote access is only granted if the user chooses to share a specific activity. The effect is similar to letting someone walk over and type on your keyboard. With current technology, it's a bit more like letting any stranger with a nametag that reads Jimmy walk over and type on your keyboard when you actually meant to invite your friend Jimmy over to help you. (Also, do note that your simile also describes the current security properties of activity installation, web browsing, Adobe-Flash playing, and perhaps of plugging in USB sticks -- that is: non-existent.) Ben Schwartz wrote: To engineers: Is sharing an activity a sufficient indication of intent from the user to execute a potentially dangerous action, such as sharing Terminal on a public collaboration server? Let's start with a more basic question: what mental model(s) of software do we want to share with our learners? Ben Schwartz wrote: An Activity can easily be stopped by a single click at any time. Pff. On Sugar today, an activity can probably reformat your hard disk, reflash your BIOS, or make toast on your IPv6-enabled toaster. (Such, by the way, is the general state of desktop security.) Your only hope of stopping a malicious activity is to cut the power. Ben Schwartz wrote: One possibility that has occurred to me is to permit unsafe sharing only with users who have already been designated as Buddies. Instead of Share with My Neighborhood, the toolbar would only offer Share with My Friends. A good design exercise that I think might shed some light on your situation would be to analyze your SharedTerm system, in both its current and in this proposed form, in terms of Ka-Ping Yee's design principles for usable security: http://zesty.ca/sid/ (Also, do let me know if you would like to pursue this course -- I would enjoy practicing with you.) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
