[Soc-coordination] Deciding on our applications
Javier Fernández-Sanguino Peña
jfs at computer.org
Fri Mar 30 18:35:14 CET 2007
On Fri, Mar 30, 2007 at 05:32:13PM +0200, Erich Schubert wrote:
> I've read through the various "security checking" proposals.
> I put one into the ineligible section, it didn't have any real content,
> so don't be surprised if counts don't match up anymore.
I actually put a very low score for those that just
> I'd count the OVAL project to the security checking proposals; I'm aware
> that they have a different focus (and it might make sense to take one of
> each), but they also are somewhat related.
I think they are not that much related:
- checksecurity: perform common security checks, oriented towards ensuring
availability, integrity and confidendiality. Slightly (but not completely)
focused towards intrusion detection in production systems. Should be
lightweight (It's Recommended: by cron, so most Debian installs would pull
it in) and driven by the host. We are looking for a rewrite of current
functionality (and maybe enhancing it with ideas from Tiger).
- OVAL: have a mechanism to review patch status for large clusters of
machines, agent-based but driven by a central host (which generates,
distributes and presents results related to vulnerability information). We
are looking on integrating an industry-standard (free-software based) into
Debian, and having an agent, server and GUI available.
Each of the projects is (more or less) a three-months man work.
> Javier, I'd like to talk to you about the OVAL thing, how much of it's
> testing etc. should be resusable/shared with a checksecurity rewrite, or
> how these projects are related to each other.
* OVAL, as it currently stands, is oriented towards patch management
of security issues. Checksecurity currently does none of this.
* OVAL's architecture is server-agent based (a server obtains the information
and tells OVAL agents what to do) while checksecurity is host-based (host
runs checks, maybe notifies some other host of the results)
Certainly, the OVAL language, in itself, could be used to define "common
security checks" but none has come around to writing the definitions of those
(as they are not even easy to write). But that's not it current focus.
> I could imagine that checksecurity could also process OVAL data provided
> by Debian on the security website etc. (am I right that Debian could use
> OVAL as a language to publish which package versions are affected by a
> certain vulnerability?)
Yes, Debian could use OVAL as a data format in which vulnerabilities were
published, that's one of the points of the OVAL project.
> One proposal mentioned SELinux. It would make a lot of sense to
> integrate some SELinux support into checksecurity and similar
> applications (e.g. checking if a daemon is running in the domain it is
> expected to on SELinux systems, to ensure that the SELinux protections
> are actually in use, especially for targeted policy)
Quite certainly, it makes a lot of sense to integrate *all* of the "security
bits and pieces" into a single application but that:
a) is a very large project, and would not be completed in GSoC's timeframe
b) should have been discussed prior to this year's GSoC.
If whomever did the checksecurity rewrite did it properly (providing a plugin
framework) and if the OVAL agent was finalised it could later one be
converted into a "plugin" that checksecurity could run (if installed) with
maybe an associated task that would pull the information from the different
data stores (DSA's are one, the Testing Security Tracker is another one).
I would prefer, however, if both projects were not combined in this GSoC's as
I don't feel somebody would be able to complete both (to satisfaction) in the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20070330/3c073fdf/attachment.pgp
More information about the Soc-coordination