Yep, the pgsql plugin makes extensive use of pg_namespace, pg_class
and pg_attribute which are system tables. These contain definitions of
every single object registered on that database server and is a major
security risk (as I pointed out, if that ulogd connection to the
database server is hijacked, then the attacker could find out what is
on that database without any problems, which is not good).
I had in mind exactly what you've suggested above - use a separate,
manually-registered table containing the table columns and their
mapping to ulogd2 parameters - much less risk and everything is
configurable, though the downside is that the two tables need to be
synchronised if the structure of the main ulogd table changes (columns
renamed or added).
One other thing which I forgot to ask: currently, the pgsql plugin uses
an unencrypted connection to the database server. I haven't studied the
underlying source code which handles pgsql-specific functions, but in
principle it is possible to use encrypted (SSL) connections to the
server by using client/server certificates. Has this been attempted and
considered to be included as an option to that particular plugin?
If not, would there be any objections if such feature is implemented
(obviously, there will be a need to add additional parameters to that
plugin to configure the type of connection, client/server/ca
certificates etc)?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
