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

[Tomeu Vizoso]

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.

Regards,

Tomeu

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