Re: [Sugar-devel] Future of Rainbow + Sugar?
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. Yeah, that's a very important point. I think we already know the kind of issues we can expect to find and maybe should think twice before throwing out all that knowledge. I don't see Rainbow in Sugar as too controversial, because: - the modifications needed to the Sugar platform are minimal, The changes to sugar might be minimal but the changes to the underlying OS are not so simple. From my (which is very basic) understanding there is patches to at least the kernel, initscripts, upstart and telepathy and possibly dbus to support rainbow. This makes it very hard to use it in a standard distro environment especially where Fedora (for example) already uses SELinux to implement some of the features of rainbow. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Mon, Mar 02, 2009 at 02:08:38PM +0100, Peter Robinson wrote: The changes to sugar might be minimal but the changes to the underlying OS are not so simple. From my (which is very basic) understanding there is patches to at least the kernel, initscripts, upstart and telepathy and possibly dbus to support rainbow. Peter, You're confusing rainbow (the activity isolation component of Bitfrost) with many other components including olpc-update, olpcrd, OFW, and hardware support. Please read http://wiki.laptop.org/go/Rainbow and let me know if you're still concerned about what's required to use Rainbow or about how I intend to make it easier still adopt. This makes it very hard to use it in a standard distro environment especially where Fedora (for example) already uses SELinux to implement some of the features of rainbow. I can see from reading the selinux-policy sources that lots of hard work has gone into confining all sorts of system services. Tell me, though -- what SELinux policy prevents a typical Abiword or Evince process, run by me from my desktop, from writing to my ~/.bashrc? Moreover, even supposing this policy exists, is it used by default on any Fedora spins, let alone on the main Fedora livecds? Rainbow has offered this safeguard, on by default on XOs, for over a year. (NB: Perhaps, we would be better served by spending our time wondering how the two technologies can complement one another, each sustaining guarantees that are too expensive [in complexity] for the other to maintain?) Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:09:26AM -0800, Carol Farlow Lerche wrote: My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), . things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. Carol, I can't promise that I've reached clearly lays out yet, but I /have/ worked a bit on unifying the Rainbow wiki page: http://wiki.laptop.org/go/Rainbow and I think that I could now use some more feedback about which parts are working for you and which parts aren't. Thanks, Michael P.S. - Other sugar folks might be interested to hear that Sascha Silbe (silbe) managed to launch some activities under rainbow inside sugar-jhbuild. You should follow up with him if you'd like to improve the system. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 18:29, Wade Brainerd wad...@gmail.com wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. Yeah, that's a very important point. I think we already know the kind of issues we can expect to find and maybe should think twice before throwing out all that knowledge. I don't see Rainbow in Sugar as too controversial, because: - the modifications needed to the Sugar platform are minimal, - most activities don't need to be modified and the ones that do, shouldn't be hard to modify (though there's the issue of unmodified X apps), - we have already agreed that we need a system-wide switch for disabling Rainbow and a way to white list activities that for some reason cannot run yet inside Rainbow. That system-wide switch means that distributors of Sugar will be the ones to decide if they want Rainbow or not. The Sugar community just listens to their deployers and tries to find a way to accommodate that need. No one is forced to use Rainbow, though it's true that activity authors need to take into account a set of limitations if they want their activities to run everywhere. Regards, Tomeu But Michael, what you seem to be asking for - someone to pick up your solo project and finish it - almost never happens in software development. Code is a personal expression of the programmer who wrote it. If it ever does get finished by someone else, it likely gets rewritten in the process. Best regards, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
The userland application privilege isolation is hugely important, as we are pushing for making our apps heavily network oriented, the risks of other network hosts trying to take advantage of vulnerable apps is huge. A problem with expanding Rainbow to other desktops is that the Rainbow model derives from the Sugar model, which is that only custom-written and therefore Sugarized programs run in the Rainbow environment. In other words, Sugar and Rainbow draw a hard line in the sand between Sugar Activities and ordinary programs. Rainbow protects Sugar Activities, but doesn't affect ordinary programs. Most other systems don't have that hard line. The shell, the compilers, the clock in the corner of your screen, the browser, are all just programs. They all run with the same privileges and can access the same files and networks. You can just run them anytime, from any shell or script. They don't have to go through a dbus interface, interact with the user, and be passed a file descriptor to read a file; they can and do just call open() or fopen(). This straightforwardness and POSIX compatability doesn't work under Rainbow. This is why so many programs needed to be patched to run under Rainbow -- and why the maintainers of those programs weren't interested in incorporating Rainbow-specific patches. If Rainbow was optional, that would be different. Programs that *want* to run with higher security and less functionality could use it. Most wouldn't even lose any functionality, because Rainbow would only be eliminating options that the programs never use. That was its design goal -- to eliminate capabilities that a program was never designed to use, so the program can't be subverted by an attacker to exploit those capabilities. Its early implementation became more of a straitjacket than a benign helper, with programs failing to run when Rainbow was turned on globally. It's a hard job to design and implement a good generic capabilities system for a POSIX environment. So far nobody has done it (including Rainbow). The basic ideas of mark programs with the capabilities they need (or don't need), and have exec() disable the ones the program doesn't need, and have programs drop excess capabilities after initializing are good ones. The devil is in the details. The kernel part is relatively simple. It's a harder job to enable capabilities that are far beyond the kernel's ability to police, like disable this program's ability to listen to a built-in microphone; that requires security-sensitive changes to a whole variety of libraries, software, and controls. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Rainbow in jhbuild would help debugging. I don't think I am along=e in using it as a development environment. -walter On Tue, Feb 24, 2009 at 12:09 PM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it - almost never happens in software development. Code is a personal expression of the programmer who wrote it. If it ever does get finished by someone else, it likely gets rewritten in the process. Best regards, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. Users naturally want to do this. To see what happens when the operating system doesn't support it, just look at the wave upon wave of e-mail viruses that plagued Windows for so many years. Without support for safe collaborative development of this sort, Sugar has little to recommend it over XFCE and similar gtk-based iconic user interfaces. We are getting there, and with the latest improvements to view-source and Rainbow, we are beginning to have the basics in place. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Carol, you make it sound as if Rainbow was new and unknown and Michael was pushing it. That's a bit unfair. Rainbow has been shipping in the OLPC releases for quite a while, and activity authors in general do know that they simply have to respect the designated directories for saving files. For example, they do know that SUGAR_ACTIVITY_ROOT (provided by Rainbow for runtime use) is something else altogether than SUGAR_BUNDLE_PATH (set by Sugar to the installation directory). Rainbow is one of the most generally useful things brought into being by OLPC. Since Sugar activities were specifically designed to work with it, it would be a shame to not use this enhanced security framework. In particular since Sugar aims at users who need all the protection they can get. Integration with jhbuild has been problematic since the rainbow demon needs to run with super user privileges, and it would need to mess with the user management of the host machine. But it should work very well in SoaS and I for one would appreciate if it was integrated and enabled there. - Bert - On 24.02.2009, at 17:56, Carol Farlow Lerche wrote: Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. So you've said in the past. What of it? I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. The justification which interests me the most goes something like: strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. The issue is that rainbow has been maintained and its downstream users (e.g. Sugar) need to give some feedback on the intermediate results so that there will be time for its upstream author to respond to that feedback. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it Thank you, no. I apologize if my writing contributed to this gross misunderstanding of my purpose. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:57 PM, Michael Stone mich...@laptop.org wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. The justification which interests me the most goes something like: strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster. See my comment regarding Backup, a far more useful and achievable solution to this problem. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. In a nutshell, all this refers to Sandboxing, which seems to be the new hotness in software security these days. I type this email in Google Chrome, which is a good example of that. There's nothing wrong with sandboxing or other new security techniques, I just argue that their purpose is *orthogonal* to the goals of Sugar. Apologies for incorrectly assuming that you wanted someone to finish Rainbow. As far as I know the current implementation is without major issues, if some of the more advanced features of Bitfrost are not yet implemented. Regards, -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. I am virtually certain that Rainbow is not the major obstacle to getting more activity developers. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. Agreed. However, what activity authors need to know about rainbow is documented, and it really is not much. For example, here http://wiki.laptop.org/go/Low-level_Activity_API#Security This is not even a full page, and if activity authors use the Python Sugar toolkit they can worry even less about this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote: Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Carol, Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. I'll see what I can cook up. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Do you have an example of documentation which you think really nailed the divide between what is needed, what exists, how good is it?, and how do I use it? Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. The purpose of the rainbow.txt document was to argue that a design /existed/ which would satisfy enough of the overall goals to be worth pursuing. The purpose of the Low-Level Activity API documentation is to explain what features of rainbow exist and can be twiddled by activities. As it happens, the main feature which exists is primitive filesystem isolation. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: How do I turn rainbow off for testing? which, in fact, is answered in the For Activity Developers section. http://wiki.laptop.org/go/Rainbow#For_Activity_Developers Obviously, a couple of people also found it helpful to tweak the isolation options in detailed ways as discussed in the API docs you cited earlier. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Carol Farlow Lerche c...@msbit.com wrote: things that the activity developers can and can't do As an aside, I yesterday uploaded a simple activity to addons.sugarlabs.org. This activity runs on os767 and soas (afaik). Your post and this discussion made me realize that I hadn't had to think about Rainbow *at all* and things Just Worked. For simple activities and/or barrier-to-entry discussions, that observation seems germane. Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
bert wrote: On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 1:30 PM, p...@laptop.org wrote: bert wrote: On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. I'm going to bow out of this thread (back to work!) but I wanted to bring up one last point regarding Rainbow's cost to Sugar. It is my sincere hope that sometime in the future Sugar will gain the ability to seamlessly launch normal X applications alongside activities. There are a great many educational Linux applications out there that would fill in gaps in our activity lineup. I fear that Rainbow will be an obstacle to achieving this goal, as we don't have the ability to fix every application in existence to conform to our non-standard security model, and emulation hacks will never just work. Best, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Wade Brainerd wad...@gmail.com wrote:
Backup, a far more useful and achievable
solution to this problem.
I don't see how Rainbow, something _working_ and pretty usable on my XO right
now, is usefully compared to backup, a solution similar in specificity to the
aphorism be careful and one that doesn't resemble anything working on my XO
right now. I think there are about a ton of threads about how backup might be
implemented on {,xs-}de...@l.o.
Regards,
-Wade
Martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I'm happy to continue this discussion off-list if you or others feel it is inappropriate to carry it on here. However, to respond to your mail: Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. I would be happy to supply detailed editorial comments to any effort you make to provide a unified Rainbow document. ... write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. I'll see what I can cook up. You might consider: Specifically list aspects of program operation that are forbidden or limited in the application, by default, under the current implementation. Tell why the restriction is there, from a user-benefit perspective. If these restrictions can be overcome by configuration files or programmatic calls, list these under the restriction description. Point out explicitly where a developer would see evidence of the restriction being called into play (which log, e.g., and where is it? Do you need to turn on logging in some way to see the messages?) You might want to create a separate tutorial from the standpoint of other desktop environment developers, along the lines of what to do to implement Rainbow in your environment. I already here voices chiming in that all anyone needs is to read the code. But could those chiming voices please recognize that there is a difference between the effort people will go to in conforming to or using a feature that they don't entirely belive in, (rather than just turning it off) compared to being provided easy access and understanding. Do you have an example of documentation which you think really nailed the divide between what is needed, what exists, how good is it?, and how do I use it? It is uncommon to document future features unless they are realistically expected to be implemented soon, except perhaps as an appendix of unresolved issues, or bugs sections as in man pages. But frequently documentation addresses features that are only present in later versions. Often this is set off by color, inline images of some kind or similar visual cues. As it happens, the main feature which exists is primitive filesystem isolation. Well, I'd stick to documenting that, and save the blue sky for an appendix. For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. Persons with a deep or even a moderate interest in security would understand that that was the case, but we're talking about a hoped-for community of activity developers including educators and learners that have so far proved unable to cross a rather high barrier of entry. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: How do I turn rainbow off for testing? which, in fact, is answered in the For Activity Developers section In this case, perhaps we should contemplate why someone would want to turn off rainbow, rather than using information that tells them what Rainbow is preventing. Can I offer the analogy of the dreaded Windows security problems in which applications written for early versions of Windows silently broke when MS introduced new access violation error returns that the programs were unaware of? These errors could often be eliminated by end users through granting constrained privileges to various Windows resources, but instead most people just did the simple thing. They ran the application as administrator (analogous to turning Rainbow off). All the bad consequences followed. Btw I don't think it was just that developers turned off Rainbow. Users did too, because activities had been written outside the context of Rainbow, then it was turned on. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Carol Farlow Lerche wrote: . the purpose (not in security speak but in terms of the benefits it brings to end users), also why should rainbow be used instead of one of the many other sets of tools available to distros for locking down a desktop (SELinux, or other LSMs)? can/should rainbow be modified to use the LSM hooks so that it can be used with standard systems? or is it really doing something that is Sugar specific? how should/could rainbow work with non-sugar apps? (normal X learning apps running on an XO to use an example raised in another post in this thread) how should/could apps work around what seems like a rainbow limitation to let one binary be used for multiple 'apps' (for example gmail + browse or the X desktop wrapper) I apologize if you already answered this in your documentation, but these sorts of concepts were not even being discussed a year or so ago, and the answers are not generally known. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 20:43, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. +1 Besides, if we didn't feel that children deserved better than the currently popular systems we would not have started Sugar development in the first place. Security is one aspect of this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi, On Dienstag, 24. Februar 2009, Wade Brainerd wrote: Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Ahem, sugar is aimed at kids, not at people developing software or learning how to do system administration. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. It seems to me your hammer is called backup. ;-) regards, Holger, who thinks that rainbow is extremly needed signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24 Feb 2009, at 17:52, Wade Brainerd wrote: On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. I do very much agree about back-ups (Martin's and others school-server back-up work is in invaluable here), but the promise of Rainbow is not just about limiting the possibilities for how a system could get accidently/maliciously wrecked. For instance, how do you like the idea of 'a friend' silently harvesting all the Journal photos your kid has taken via a compromised/modified activity**? **actually Pippy and the slideshow example really creeps me out for just that reason – remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? I know Rainbow, as currently implemented, is lacking in certain areas – but Rainbow is providing something I think is valuable, that's not available elsewhere, and in a manor appropriate for the non-specialist target audience. --Gary P.S. Maybe I'm just paranoid; v.happy to be corrected. -Wade ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 5:24 AM, Michael Stone mich...@laptop.org wrote: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, Hi Michael, what rainbow provides is very important. The trusted-OS checks from the firmware up are important. The userland application privilege isolation is hugely important, as we are pushing for making our apps heavily network oriented, the risks of other network hosts trying to take advantage of vulnerable apps is huge. You are now talking about the implementation of rainbow that provides userland privilege isolation. One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. Maybe rainbow could insta-isolate creating selinux profiles for activities? Maybe my ignorance on matters selinux is showing? ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Martin Langhoff wrote: Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. --Ben P.S. The SELinux entry on Wikipedia contains the following gem: Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Benjamin M. Schwartz wrote: Martin Langhoff wrote: Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). So does anyone want to become expert at writing SELinux policy? Someone who might benefit from a Red Hat internship in Westford at the feet of the master of SELinux, Dan Walsh? http://danwalsh.livejournal.com/26904.html --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote: You are now talking about the implementation of rainbow that provides userland privilege isolation. For the record, rainbow only describes the userland privilege isolation part. The rest is just OFW, olpcrd, olpc-update, OATS (If somebody knows a better way to explain this stuff, speak up!) One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. I think this would have the effect of making rainbow much less generic than it currently is. On the other hand, it might still be worth doing if it made it much easier to implement important features. Maybe rainbow could insta-isolate creating selinux profiles for activities? I've been wondering about this for some time. Basically, while my reaction when it was initially proposed it was lukewarm, for all the usual reasons [1]. Since then, I've been very gradually warming to the idea, in part as SELinux matures, in part as I get to know the technology and people [2] better, and in part as I run up against limitations of the simple Unix approach that I've taken for the last year. Therefore, while it's not how /I/ intend to proceed in the near future, I'm happy to try to work with people who feel differently. I definitely have some ideas on the subject. Michael [1]: http://lists.laptop.org/pipermail/security/2008-January/000370.html [2]: http://danwalsh.livejournal.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote: Sugar/OLPC simply never had SELinux experts I'm pretty sure this is false. For instance, I know that ancient OLPC+RH kernels has SELinux enabled and I know that the SELinux folks at RH have always been excited to help me to understand their work whenever I took the time to ask them questions every few months. It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. This is actually not such a big deal, in my opinion. The killer problem, as I learned from the vserver experience, is that novice activity authors /must/ be able to debug their work in any system which we might hope to ship. I don't think that I have very good ideas on how to make this part workable with technologies that are more complicated or more obscure than Unix DAC. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote: remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? Unfortunately, no. No one has yet completed an implementation of the gates needed to guard access to the DS and the glue needed to know which DS entries to fork over to which activities. (I got partway through an implementation of the gates, which are actually fairly simple, but didn't get to the glue. [8.2.0 intervened.] Later, Scott approached the problem from a completely different angle, i.e. with FUSE filesystems. Hopefully, though, Tomeu's simplified data store will make further work in this area a bit simpler, if any such work occurs.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 12:21 PM, Michael Stone mich...@laptop.org wrote: For the record, rainbow only describes the userland privilege isolation part. You're right. I conflated the overarching shadow of bitfrost with rainbow. My bad. I think this would have the effect of making rainbow much less generic than it currently is. I'm intrigued by your comment. Do you mean less portable, and in that case what kind of portability are you thinking of? selinux does look more generic than rainbow... And we don't have to go own the selinux path. Is smack simpler, more appropriate to our needs? As you say, selinux, smack and friends have moved forward a lot in the last 2 years. Implementation/documentation/understanding of them has matured enormously. Just having 'permissive' mode is a fantastic thing when developing sw. cheers m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Tomeu Vizoso wrote: Michael, when several weeks ago you showed me in #sugar your patches to Sugar and explained the new rainbow concept, I told you that it seemed a good idea and that the patches looked pretty good. As you said Rainbow wasn't ready for 0.84, I told you that we would talk again when work on 0.86 starts. Which it hasn't yet, afaik. So I don't think you should feel sad because of our schedule. All projects need one and it's good to try stick to it. I will repeat that I think Rainbow can be a very important part of Sugar and that we should see how integration should happen, but I'm afraid I cannot directly help you with coding, etc because as you know I'm very tied with 0.84 right now. I think, this describes quite well the current where we stand currently regarding inclusion of Rainbow. I think it is an interesting part to tackle for 0.86. This release cycle was, in terms of changing resources and environment conditions, even worse than the last one. I guess, it can always get worse ;D So there was only so much we could do - and many things that fell of the plate. Anyhow, let's try to look forward - and see what we can do for 0.86. Thanks, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
