Re: Using a database as backend for Nessus (current state and volunteering for development)

----------------------
William Heinbockel
Information Security Incident Response Assistant
Co-op Risk & Safety Management
Rochester Institute of Technology
E-mail: [email protected]

On Tue, 14 Jan 2003, Thomas Reinke wrote:

> While a db back-end is a great idea, keep in mind one
> _very_ important design issue.  If you have a db, and
> you issue a new release of Nessus, you don't have nearly
> the same flexibility changing the db design as you do
> changing nessus functionality.

I have thoroughly examined a majority of the Nessus code.
Renaud has done an excellent job of make Nessus very flexible,
while still maintaining functionality.
The only case that I would believe your statement to hold true is
if Renaud et al. would do a rewrite of the entire Nessus code.
Currently, the way Nessus is set-up I could rewrite NTP and change some
of the backend and structs, and as long as the DB code was integrated into
the code (nessus/nessusd or both), instead of a hack on top of it, you
shouldn't have any major problems (if any at all) with porting it along
with the Nessus updates.

> 
> People will have lots of scans in the db, and if you go
> and change the schema, you're now forced to do a db conversion.
> It's not impossible. Not even terribly difficult. But it
> certainly can be prone to problems.

This will exist for any database.  This is being designed as
a tool to assist users/admins.  I'm sure many avid Nessus users
have already created a script to parse through Nessus reports.
If the database was implemented as an extension of nessusd (the server),
you could easily dump the information.  Nessus stores a lot of info,
but only some of it gets transfered to the client for the reports :)

> 
> You'll need to do things like marking the schema, and
> when a new release of Nessus tries to access an old schema
> oriented db, deny the transactions and indicate a conversion
> needs to be done.

I don't think that needs addressed at this moment.
Porting old databases to new databases is just the task of translating
the old protocol to the new.  If we make the DB complete the first time,
there should be no need to convert it to a new schema.

> 
> Not only that, but you'll be faced with possibly multiple
> conversions. At minimum, each schema change will require
> a conversion script. At worst, you'll need to accomodate
> several different types of conversions as people who skip
> releases of several different schema changes want to bump
> themselves up to the latest and greatest without necessarily
> going through the conversion from all the previous releases
> (unless you can make that relatively painless for them).
> 
> There's also the minor issue of permissions - e.g. with
> postgres, afaik, one cannot be root and access the db
> (or at least its HIGHLY discouraged). Since Nessus needs
> to run as root, you have a minor problem now that you need
> to solve if the server is the one accessing the DB. From
> that perspective, it may be worthwhile to completely
> separate out the DB management actions from the Nessus
> daemon.
> 
> Cheers, Thomas
> 
>