[Openvas-commits] r971 - trunk/doc/website
scm-commit@wald.intevation.org
scm-commit at wald.intevation.org
Fri Jun 27 10:39:55 CEST 2008
Author: jan
Date: 2008-06-27 10:39:55 +0200 (Fri, 27 Jun 2008)
New Revision: 971
Added:
trunk/doc/website/openvas-cr-13.htm4
Modified:
trunk/doc/website/openvas-crs.htm4
Log:
Adding CR #13 (ovaldi/OVAL)
Added: trunk/doc/website/openvas-cr-13.htm4
===================================================================
--- trunk/doc/website/openvas-cr-13.htm4 2008-06-26 13:19:54 UTC (rev 970)
+++ trunk/doc/website/openvas-cr-13.htm4 2008-06-27 08:39:55 UTC (rev 971)
@@ -0,0 +1,367 @@
+m4_dnl -*-html-*-
+m4_include(`template.m4')
+
+m4_dnl OpenVAS
+m4_dnl $Id$
+m4_dnl Description: OpenVAS Change Request #13
+m4_dnl
+m4_dnl Authors:
+m4_dnl Bernhard Herzog <bernhard.herzog at intevation.de>
+m4_dnl
+m4_dnl Copyright:
+m4_dnl Copyright (C) 2008 Intevation GmbH
+m4_dnl
+m4_dnl This program is free software; you can redistribute it and/or modify
+m4_dnl it under the terms of the GNU General Public License version 2,
+m4_dnl as published by the Free Software Foundation.
+m4_dnl
+m4_dnl This program is distributed in the hope that it will be useful,
+m4_dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+m4_dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+m4_dnl GNU General Public License for more details.
+m4_dnl
+m4_dnl You should have received a copy of the GNU General Public License
+m4_dnl along with this program; if not, write to the Free Software
+m4_dnl Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+
+
+PAGE_START
+<h2>OpenVAS Change Request #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server</h2>
+
+Status: In discussion.
+
+<h3>Purpose</h3>
+
+<p>
+ To have OpenVAS Server treat and execute OVAL tests analog to NASL tests (though done via ovaldi
+ and being aware it will only be possible for a subset of OVAL tests)
+ and use the feed service for distributing new OVAL tests.
+</p>
+
+<h3>References</h3>
+
+<p>
+ <a href="http://oval.mitre.org/">General information about OVAL
+ (http://oval.mitre.org/)</a><br>
+
+ <a href="http://sourceforge.net/projects/ovaldi/">The ovaldi
+ Interpreter</a>
+</p>
+
+<h3>Rationale</h3>
+
+<p>
+ OVAL -- Open Vulnerability and Assessment Language -- is an XML-based
+ language for descriptions of vulnerability tests (among other things).
+ As such its scope overlaps to a large extent with OpenVAS NVTs and it
+ would be very useful to have some sort of support for OVAL in OpenVAS.
+ OVAL vulnerability definitions for a variety of systems are available
+ from mitre.org, and at least RedHat also publishes security advisories
+ in <a href="https://www.redhat.com/security/data/oval/">OVAL form</a>.
+</p>
+
+<p>
+ Integrating an OVAL interpreter in OpenVAS in some form would make
+ OVAL descriptions more or less automatically usable with OpenVAS.
+ E.g. if a vendor releases all security advisories as OVAL descriptions
+ corresponding checks would be available for OpenVAS immediately
+ without having to write new NASL scripts. However, for the time being it
+ is expected to have at least the local security checks work this way,
+ which is an area for which currently most OVAL tests are published.
+</p>
+
+<h3>Effects</h3>
+
+<p>
+These effect only apply for users who configure OpenVAS to use
+ovaldi.
+</p>
+
+<ul>
+ <li>
+ OpenVAS will be able to run NVTs described by OVAL documents.
+ </li>
+ <li>
+ The OpenVAS Feed will either be extended to cover OVAL files or a
+ second feed with OVAL files will be added which then needs to be
+ configured explicitely.
+ </li>
+ <li>
+ OVAL files will consume storage on the OpenVAS Server Side, the amount
+ is not clear yet.
+ </li>
+</ul>
+
+<h3>Design and Implementation</h3>
+
+<p>
+ The ovaldi interpreter will be run as a sub-process of openvasd and be
+ able to access the openvasd's knowledge base (read-only) to retrieve information
+ gathered by other NVTs. Results are returned to openvasd for writing it into the
+ knowledge base. The rest of the this section explains the potential problems and proposed
+ solutions in more detail.
+</p>
+
+<h4>Run Tests Against the OpenVAS Knowledge Base</h4>
+
+<p>
+ OpenVAS runs as a server that performs security checks on remote
+ systems, whereas ovaldi is intended to be run on the system to be
+ checked. This fundamental difference means that ovaldi examines the
+ local system to check whether the criteria of an OVAL definition match
+ the system, accessing local files directly or querying the system's
+ database of installed software packages. OpenVAS, on the other hand,
+ typically runs some NASL scripts to detect the remote host's operating
+ system and to e.g. get a list of installed packages. This information
+ is inserted into the knowledge base and individual NVTs later simply
+ query the knowledge base.
+</p>
+
+<p>
+ We will have to reimplement the tests ovaldi performs so that they use
+ the knowledge base instead. This can be done relatively easily as
+ described in the section <a href="#openvas-probes"> "OpenVAS Probes in
+ ovaldi"</a> below.
+</p>
+
+<p>
+ Of course, tests run against the knowledge base will not be able to
+ run tests that need information not currently available from the
+ knowledge base. The OVAL definitions for RedHat systems, for
+ instance, include tests that check whether a given RPM was
+ cryptographically signed with a specific key. This information can be
+ retrieved from the RPM database on the remote system, but OpenVAS
+ currently does not do that.
+</p>
+
+<p>
+ Also, at first we would probably not implement all the tests that OVAL
+ supports, only the ones we need for the subset of OVAL definitions we
+ support initially.
+</p>
+
+
+<h4>Report Test Results to openvasd</h4>
+
+<p>
+ Per default ovaldi outputs the results of the tests in the form of XML
+ files and also generates an HTML file from those. To be usable for
+ OpenVAS it would be necessary to report the results back to the
+ openvasd. The technical details of this are outlined
+ in <a href="#reporting-to-openvas">"Ovaldi Reporting Back to
+ OpenVAS"</a> below.
+</p>
+
+<h4>Reporting Metadata</h4>
+
+<p>
+ In addition to results, ovaldi will have to report the metadata of the
+ individual tests to openvasd too. The metadata include the
+ descriptions of the tests, which systems are affected, what the
+ vulnerability is, references to CVEs, etc. Since ovaldi includes this
+ metadata in the reports it generates, it shouldn't be difficult to
+ report this information to openvasd, too.
+</p>
+
+<p>
+ However, it should be possible to extract this information from the
+ descriptions before actually running the tests so that the OpenVAS
+ client can show a list of the tests to let the user select which
+ subset of tests to run.
+</p>
+
+<p>
+ The technical details of this are outlined
+ in <a href="#reporting-to-openvas">"Ovaldi Reporting Back to
+ OpenVAS"</a> below.
+</p>
+
+<h4>Map OVAL IDs to OpenVAS OIDs</h4>
+
+<p>
+ NVTs are identified by OIDs within OpenVAS
+ (once <a href="file:///local-vol1/bh/openvas/misc/doc/website/openvas-cr-1.html">Change
+ Request #1</a> is implemented). OVAL descriptions are identified by
+ an ID which is a character string of the form:
+</p>
+
+<pre>
+ oval:<reverse domain>:def:<num>
+</pre>
+
+<p>
+ Where <reverse domain> is a domain name in reverse order, for instance
+ org.openvas instead of openvas.org. and <num> is an integer. Since the
+ OVAL IDs are a completely new namespace, we should introduce a new OID
+ sub-tree for them, e.g. (following Change Request #1):
+</p>
+
+<pre>
+ 1.3.6.1.4.1.25623.1.2
+ = iso.org.dod.internet.private.enterprise.OpenVAS.NVT.OVAL
+</pre>
+
+<p>
+ Below that we need one level for each of the domains that occur in
+ OVAL IDs and then another below that for the domain specific
+ <num>s. The main problem then is how to map the domain names to
+ numbers.
+</p>
+
+<p>
+ In practice there will only be a few publishers of OVAL definitions.
+ Currently most come from oval.mitre.org. We could either assign the
+ numbers ourselves (org.mitre.oval -> 1, com.redhat.rhsa -> 2,
+ etc.) or we could reuse the OIDs the publishers already have in the
+ private enterprise OID namespace. Reusing the private enterprise OIDs
+ would lead us to the following examples:
+</p>
+
+
+<table>
+ <tr>
+ <th>OVAL ID</th><th>OpenVAS OID</th>
+ </tr>
+ <tr>
+ <td><tt>oval:org.mitre.oval:def:5327</tt></td>
+ <td><tt>1.3.6.1.4.1.25623.1.2.115.5327</tt></td>
+ </tr>
+ <tr>
+ <td><tt>oval:com.redhat.rhsa:def:20080177</tt></td>
+ <td><tt>1.3.6.1.4.1.25623.1.2.2312.20080177</tt></td>
+ </tr>
+</table>
+
+<p>
+ In any case, we need to maintain an explicit mapping between the
+ domains used in OVAL IDs and the domain-numbers used in OpenVAS OIDs.
+ The mapping between domains and OIDs is not unambiguous because a
+ vendor could start to use more than one domain name for OVAL IDs.
+ However, reusing vendor OIDs for OpenVAS NVT OIDs in the fashion
+ described above has the advantage that OpenVAS users trying to use
+ OVAL definitions from a new source could derive the correct OID on
+ their own if necessary.
+</p>
+
+<h4>Integrity Check of OVAL Definitions</h4>
+
+<p>
+ OpenVAS uses OpenPGP signatures to check
+ the <a href="http://www.openvas.org/trusted-nvts.html">integrity of
+ NASL files</a> and will not run any NASL file that does not have a
+ valid signature from a trusted key. Something like this would be
+ desirable for the OVAL definitions too. The easiest way to support it
+ would be to use the same signature mechanism as for NASL scripts and
+ have openvasd check the signatures before starting the oval
+ interpreter.
+</p>
+
+<p>
+ ovaldi has an integrity check built in, though. It compares the
+ md5sum of the file with an md5sum given on the command line. It would
+ be possible to extend ovaldi to do the OpenPGP signature check instead
+ of having openvasd do it.
+</p>
+
+<h4>Changes to openvasd</h4>
+
+<p>
+ openvasd will run ovaldi as a sub-process.
+</p>
+
+<p>
+ Potential problems:
+ <ul>
+ <li>
+ <p>
+ NASL NVTs contain one test per file whereas OVAL often has
+ multiple tests per file. This may pose a problem if the
+ assumption of one test per file is very widespread in the
+ OpenVAS code.
+ </p>
+ </li>
+ </ul>
+</p>
+
+
+<h4><a name="openvas-probes">OpenVAS Probes in ovaldi</a></h4>
+
+<p>
+ The ovaldi sources are organized into several components:
+ <ul>
+ <li>
+ a general OVAL interpreter</li>
+ <li>
+ <p>
+ "probes" implementing the various tests supported by OVAL
+ </p>
+ <p>
+ The probes are further split into several sub-directories, with one
+ directory each for:
+ <ul>
+ <li>platform independent probes</li>
+ <li>probes for windows</li>
+ <li>probes for solaris</li>
+ <li>probes for linux</li>
+ </ul>
+ </p>
+ </li>
+ </ul>
+</p>
+
+<p>
+ Each of the platform specific probes directories contains a class
+ called ProbeFactory which is used to instantiate the objects
+ implementing the actual tests. Which probe factory is used simply
+ depends on which one is linked into the final executable. The
+ directory with the platform independent probes doesn't have a probe
+ factory. The platform specific factories instantiate the platform
+ independent probes too.
+</p>
+
+<p>
+ This design of course implies that a single ovaldi executable can only
+ execute the OVAL descriptions for one platform. Given the intended
+ way ovaldi operates -- running on the system which is to be tested --
+ this is not a limitation, though.
+</p>
+
+<p>
+ To get ovaldi to access the OpenVAS knowledge base we can simply treat
+ OpenVAS as a new platform and introduce a new probe factory that
+ instantiates probes that refer to the knowledge base instead of the
+ local system.
+</p>
+
+<h4><a name="reporting-to-openvas">Ovaldi Reporting Back to OpenVAS</a></h4>
+
+<p>
+ When integrated with OpenVAS, ovaldi needs to report metadata and test
+ results back to openvasd. The general approach to this would be to
+ replace the code that generates the XML based reports with code that
+ transmits the information to openvasd. We will likely have to replace
+ the main driver code (src/Main.cpp) with our own version, because the
+ current implementation hard-wires too much of the reporting for our
+ purposes. It should not be difficult to simply link with our version
+ of Main.cpp instead of the one coming with ovaldi.
+</p>
+
+<h4>Implementation TODOs</h4>
+
+This is a unsorted initial collection of explicit changes/extensions to
+the code:
+
+<ul>
+<li> openvas-plugins/scipts/gather-package-list.nasl: Extend (perhaps
+ optional) to retrieve signatures for packages.
+<li> ovaldi: src/Main.cpp: Change report driver code to serve the
+ needs of OpenVAS.
+<li> ovaldi: Extend with a OpenVAS-KB probe factory
+</ul>
+
+<h3>History</h3>
+
+<ul>
+<li> 2008-06-26 Bernhard Herzog <bernhard.herzog at intevation.de>:<br>
+ Initial text.</li>
+</ul>
Modified: trunk/doc/website/openvas-crs.htm4
===================================================================
--- trunk/doc/website/openvas-crs.htm4 2008-06-26 13:19:54 UTC (rev 970)
+++ trunk/doc/website/openvas-crs.htm4 2008-06-27 08:39:55 UTC (rev 971)
@@ -52,6 +52,7 @@
<li> <a href="openvas-cr-10.html">OpenVAS Change Request #10: Remove support for non-SSL connections in OpenVAS-Client</a> (done)
<li> <a href="openvas-cr-11.html">OpenVAS Change Request #11: Make OpenVAS-Client use (and depend on) glib</a> (done)
<li> <a href="openvas-cr-12.html">OpenVAS Change Request #12: Replace NTP with OTP</a> (in progress)
+<li> <a href="openvas-cr-13.html">OpenVAS Change Request #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server</a> (in discussion)
</ul>
<h3>How to write a change request</h3>
More information about the Openvas-commits
mailing list