[IAEP] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)

Tomeu Vizoso tomeu at sugarlabs.org
Mon Sep 21 15:45:16 EDT 2009

On Mon, Sep 21, 2009 at 19:25, Bernie Innocenti <bernie at 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.



«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David

More information about the IAEP mailing list