[Soc-coordination] Deciding on our applications

[Javier Fernández-Sanguino Peña]

On Fri, Mar 30, 2007 at 05:32:13PM +0200, Erich Schubert wrote:
> Hi,
> 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.

Not much:

* 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
available timeframe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20070330/3c073fdf/attachment.pgp