On Mon, Sep 21, 2009 at 19:25, Bernie Innocenti <ber...@codewiz.org> wrote: > [cc += mstone] > [cc -= everyone else] > > El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: >> I agree with your statement about security updates being what is >> desired here However, you can have bugs elsewhere >> in the stack which can cause problems even if all anyone ever runs >> directly are Sugar activities: >> >> 1. Single packet DOS attacks against the kernel. > > Yes, but the vast majority of these actually affect weird network > protocols that nobody's using (such as IPX or AFP) or weird IP options > that are not normally exploitable with a regular Internet client. > > >> 2. Overflow bugs in the DNS resolver libraries of the system which are >> triggered by simply doing a DNS query from the browser. (Implies no >> bug in the browser itself.) > > Yes, those were really scary... the DNS code is as ugly and unsafe as > all ancient BSD code is. > > >> 3. Overflow bugs in ANY non-Sugar library/program which is used by an >> Activity and whose parameters come from data >> which might be obtained from the Internet. Perhaps gnome libraries? >> Python interpreter/core libraries? I believe Read is a wrapper for >> evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. >> Any activity which wraps a standard Linux program is a potential >> problem. > > Indeed. This is one more reason why I dislike the notion of drawing a > straight line in across a modern distribution and call everything on one > side "system" and everything on the other side "applications". > > We have very advanced package systems in Linux, we don't need to regress > to Windows-era tools that can't upgrade the system and its applications > consistently. > > If it were on me, I'd kill the XO bundle format and find a different way > to enable unprivileged installation of activities > > Presently, giving out root to activities would not even constitute an > actual regression in security, since we do not have a fully functional > version of Rainbow anyway. But I agree we should fix this weakness one > day. > > >> Sure an activity can attempt to filter out bad data. I see this as >> getting into the anti-virus signature game though. Every time an >> activity is modified to filter out some new variant the attacker will >> just change their data slightly by adding padding, etc. Maybe it >> wouldn't be as bad as I suggest, but it could get ugly fast and >> activity performance would suffer as data was parsed in two places >> (wrapper and core program). We are not yet a target because most >> Sugar installations (XO-1s) are slow and at the end of really slow >> network pipes. Always-on Sugar workstations in developed world >> schools sound like a much better target. Not as nice as ubiquitous >> Windows boxes, but still of interest. > > I think partitioning security using native UNIX concepts (uids and > permissions) can be done effectively with a negligible performance hit. > It's technically feasible, and Michael Stone has a 90% finished > implementation of this concept. Now all we need to do is the *other* > 90% of the work to make it ready for production :-) > > >> Even RedHat's $30 pricing for desktop support for educational users is >> higher then I believe SoaS (or its equivalent) needs to support. >> Tomeu's CentOS suggestion is more plausible to me. > > I wasn't suggesting paying Red Hat to support us. I was suggesting that > some companies -- like, for example, Solution Grove -- could offer such > long-term support service to schools for a fee. > > Such companies could decide to create a CentOS based spin of SoaS, or > backport the security fixes themselves, or maybe even ensure that major > OS upgrades are synchronized with the beginning of the school year and > work seamlessly for the all the hardware they support. > > It's really up to them to figure out what makes their own customers > happy. Sugar Labs does not need to spend a single buck on this, exactly > the same way the Kernel Hackers don't need to care about linux-2.6.18 > today... unless they're employed at Red Hat, of course! ;-)
Well, if we decide that future releases of Sugar should run ok on the next major release of CentOS, we cannot depend on later versions of python, gtk, etc. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
