Mailing List Archive

William Heinbockel wrote:
> Does anyone here have any experience with making configure scripts?
> I think Renaud uses autoconf, but I have no clue on how to append
> to his stuff to have it check for the mysql.h library.
I do have experience with autoconf scripts. Let me give it a try.

>
> If the library is there, we might need to check to see if it is
> thread-safe. When the qualifications are met, then nessusd
> needs compiled with USE_MYSQL (or similar).
>
> I have no idea on how to go about doing this.
> If someone could explain to me how to do it, it would be greatly
> appreciated.

IMHO we should not be making something too mysql-dependant. The use of
the database should be something to be selected the same way some
experimental features are. Thus a --enable-database should plug-in the
code for mysql/postgresql/whatever..

The DB code should be generic enough so that users can select whatever
database they want and using #ifdefs include the proper code. We need a
generic open_database function which would call whatever database the
user has configured.


Javi

On Mon, 10 Feb 2003, Javier Fernandez-Sanguino wrote:

> William Heinbockel wrote:
> > Does anyone here have any experience with making configure scripts?
> > I think Renaud uses autoconf, but I have no clue on how to append
> > to his stuff to have it check for the mysql.h library.
> I do have experience with autoconf scripts. Let me give it a try.
>
> >
> > If the library is there, we might need to check to see if it is
> > thread-safe. When the qualifications are met, then nessusd
> > needs compiled with USE_MYSQL (or similar).
> >
> > I have no idea on how to go about doing this.
> > If someone could explain to me how to do it, it would be greatly
> > appreciated.
>
> IMHO we should not be making something too mysql-dependant. The use of
> the database should be something to be selected the same way some
> experimental features are. Thus a --enable-database should plug-in the
> code for mysql/postgresql/whatever..
>
> The DB code should be generic enough so that users can select whatever
> database they want and using #ifdefs include the proper code. We need a
> generic open_database function which would call whatever database the
> user has configured.
>
>
> Javi
>
>

The best option to incorporate multiple databases is to write libraries
that Nessus can use for the database calls. If people want to write
database specific code (similar to the code I have for mySQL), it can
easily be incorporated into the server code. That is why we need to
iron out a common schema so that all of the database calls through
Nessus are similar.

I agree that the code should be initially compiled with the preprocessor
directives, so that only the necessary code and C APIs are compiled in.
That's why the stuff needs put into the configure script. The necessary
APIs need to be present and their exact location needs to be given to
the compiler. Versions and other items might need to be checked to verify
that the API will work with the Nessus DB code.
Also, it might be useful to put in code to the Preferences and Rules so
that an admin can control who can use the database and they could run
Nessus without storing the results to the DB.

----------------------
William Heinbockel
Information Security Incident Response Assistant
Co-op Risk & Safety Management
Rochester Institute of Technology
E-mail: wjh3710@rit.edu

William Heinbockel wrote:
> The best option to incorporate multiple databases is to write libraries
> that Nessus can use for the database calls. If people want to write
> database specific code (similar to the code I have for mySQL), it can
> easily be incorporated into the server code. That is why we need to
> iron out a common schema so that all of the database calls through
> Nessus are similar.

I think that the code you are writting provides the common functions all
database stubs should include. SQL calls should probably be more or less
the same, so I believe your code could be used as a common base. I'm
thinking something along the lines of :

update_plugin( struct arglist * globals, char * plugin_id, char * ip,
char * status )
{
#ifdef USE_MYSQL
MYSQL * conn = (MYSQL *)arg_get_value( globals, "mysql" );
#endif
#ifdef USE_POSTGRESQL
PSQL * conn = (PSQL *) arg_get_value( globals, "postgresql" );
#endif
char * session_id = (char *)arg_get_value( globals, "SESSION_ID" );
(...)
sprintf( query, "UPDATE Host SET Status=\"%s\" WHERE Host_IP=\"%s\"
AND SessionID=\"%s\" AND PluginID=\"%s\"", status, host_ip, session_id,
plugin_id );
#ifdef USE_MYSQL
mysql_escape_string( to_send, query, strlen( query ));
mysql_query( conn, to_send );
#endif USE_MYSQL
#ifdef USE_POSTGRESL
postgresql_escape_string( to_send, query, strlen( query ));
postgresql_query (conn, to_send);
#endif
(...)


Note that the call gets made to update_plugin and not
mysql_update_plugin. Since the SQL query is probably going to be the
same across all databases it makes sense to make it this way. Doesn't it?

That way only the calls specific to a given database (retrieve the
handle for connection to it, make the sql query...) are done through
function calls specific to the database while the other functions are
common to all databases. From your save_mysql.c code: create_host_table,
create_detected_services_table, create_vulnerability_table,
create_session_table, create_exec_plugins_table, create_tables,
open_connection, new_scan_session, scan_session_complete, new_host_scan,
close_connection, update_host_scan, new_plugin, and update_plugin.

>
> I agree that the code should be initially compiled with the preprocessor
> directives, so that only the necessary code and C APIs are compiled in.
> That's why the stuff needs put into the configure script. The necessary
> APIs need to be present and their exact location needs to be given to
> the compiler. Versions and other items might need to be checked to verify
> that the API will work with the Nessus DB code.

Yes, we probably have to decide a version for each database schema.
This version should be included in the script that created the database
the first time and the DB code should check wether it's the same they
are expecting. That way we shouldn't have problems when we update the
schema and people are using old databases.


> Also, it might be useful to put in code to the Preferences and Rules so
> that an admin can control who can use the database and they could run
> Nessus without storing the results to the DB.

Yes. That's an interesting feature, hadn't thought of it.

Regards

Javi