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

[Bernie Innocenti]

[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! ;-)

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/