[OLPC Security] OLPC and Fedora Security response

[Lubomir Kundrak]

Hi,

Pardon for the late reply, I didn't want to respond until I study your
update process and it got sidetracked somehow.

On Tue, 2008-02-26 at 16:59 -0500, Michael Stone wrote:
> Lubomir,
> 
> First, thanks very much for contacting us.
> 
> > I am wondering how Fedora security response team can be helpful to the
> > OLPC project software: We currently monitor various sources for security
> > issues that affect software shipped in Fedora distribution, notify the
> > developers about relevant flaws that affect us via bugzilla and track
> > progress on fixing.
> 
> We can certainly use any help that you can offer. :)
> 
> > As Fedora project developers and infrastructure are involved in
> > development and packaging of OLPC software, we can add OLPC to list of
> > software we track security issues for.
> 
> This would be wonderful - please do so. Public notifications could be
> directed to devel at lists.laptop.org or to security at lists.laptop.org
> depending on how broadly you want to publish the information within the
> OLPC community. Private notifications can be sent to
> security-notifications at rt.laptop.org, which will be our
> controlled-distribution mail queue for security notifications.
> 
> > I'm specifically interested in how are security issues treated currently
> > -- how do you deploy updates and when. 
> 
> To date, all security updates have been provided as a part of our
> regularly scheduled releases. However, necessity has forced us to
> develop an 'unscheduled software release process' in order to control
> the risks incurred by changing our software to support deployments (in
> Uruguay, Mongolia, and now, Peru) or to fix crucial late-breaking bugs:
> 
>   http://wiki.laptop.org/go/Unscheduled_software_release_process
> 
> > Do you fix only issues of some specific severity or all of them? 
> 
> As the 'Proposal Criteria' section suggests, we're most interested in
> security issues that threaten theft-deterrence or child safety; or that
> threaten the educational utility of large numbers of laptops.

Actually we can hardly deal with physical safety. We deal with software
packages and flaws with them. While monitoring many sources for
information about flaws, triage them and get developers fix those.

For example in Fedora we try to fix all vulnerabilities, even ones with
very low impact. We keep status of flaws in packages [1] and inform the
respective maintainers via Bug tracking system when their action to roll
packages and do an update is needed.

[1] For fedora 8 it looks like this:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/f8?root=fedora&view=markup

> > What kind of input from SRT would be interesting to you?
> 
> I'm not terribly familiar with what kind of output the SRT usually
> produces. Could you direct me to some examples of your work so I can
> give you a better answer?

See above statement.

In order for me to understand how do you do the updates; The OLPC
software distribution contains a gecko based web browser which fairly
often contains flaws exploitable by visiting a malicious web page and is
considered critical by Red Hat. Do you do unscheduled updates for those?
Or do you hold them until next scheduled update period?

When you do a scheduled software update, do you care about known
security flaws to be fixed? If yes, what can SRT do is maintain a file
similar to [1] for packages that are distributed on laptops and file
bugs for respective maintainers so it would be easy to see which
outstanding security flaws of various impact are present at any time, so
that it can be easily checked if something important is not forgotten
for the release.

It would take little extra work for SRT, as our tools and processes
already do extensively take advantage of various pieces of Fedora
infrastructure, which is also used by OLPC (koji buildsystem, CVS, etc.)

> Michael
-- 
Lubomir Kundrak (Red Hat Security Response Team)