[PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Hello,

I'm a developer of SE-PostgreSQL which is an enhancement of
database security using SELinux. It enables to apply the
security policy of the operating system on accesses to
database objects also.
It makes an access control decision and audit messages, but
these are not written out to system audit mechanism.

I believe our preferable behavior is the system audit collects
all the audit messages come from SELinux, not a logfile of
PostgreSQL.

Currently, the audit-libs has an interface to write a message
come from userspace avc, but some of parameter is not suitable
for the reference monitor in database management system.

This patch adds a new interface as follows:
    int audit_log_database_message(int audit_fd, int type,
                                   const char *message,
                                   const char *hostname,
                                   const char *addr,
                                   const char *dbuser);

It is differ from audit_log_user_avc_message() in the point of
a new parameter of dbuser, instead of tty and uid.
I don't think these are meaningful information for DBMS, but
we would like to record what database user invokes this audit
record.

Please any comments.

Thanks,

KaiGai Kohei wrote:
> 2. System audit integration
> 
> Now, SE-PostgreSQL writes out its access denied message into
> the logfile of PostgreSQL (/var/log/sepostgresql.log).
> But it is more desirable approach to write out them into system
> audit mechanism, because any other SELinux related messages
> are collected here and utilities like audit2allow is available.
> 
> TODO:
> - changes in the security policy:
>   We need to allow postgresql_t to write audit messages.
>   In addition, the backend process need to run with cap_audit_write.
> 
> - a new interface in audit-libs:
>   The current audit-libs has the following interface.
> 
>     extern int audit_log_user_avc_message(int audit_fd, int type,
>             const char *message, const char *hostname, const char *addr,
>             const char *tty, uid_t uid);
> 
>   But some arguments are not meaningful in SE-PostgreSQL.
>   I would like to write out database role here, instead of tty and uid.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: audit-libs-database-message.patch --]
[-- Type: text/x-patch, Size: 2783 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 audit_logging.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libaudit.h      |    3 ++
 2 files changed, 60 insertions(+)

Index: audit/lib/libaudit.h
===================================================================
--- audit/lib/libaudit.h	(revision 267)
+++ audit/lib/libaudit.h	(working copy)
@@ -562,6 +562,9 @@
 	const char *old_seuser, const char *old_role, const char *old_range,
 	const char *host, const char *addr,
         const char *tty, int result);
+extern int audit_log_database_message(int audit_fd, int type,
+	const char *message, const char *hostname, const char *addr,
+	const char *dbuser);
 extern int audit_log_user_command(int audit_fd, int type, const char *command,
         const char *tty, int result);
 
Index: audit/lib/audit_logging.c
===================================================================
--- audit/lib/audit_logging.c	(revision 267)
+++ audit/lib/audit_logging.c	(working copy)
@@ -623,6 +623,63 @@
 
 /*
  * This function will log a message to the audit system using a predefined
+ * message format. This function should be used by database management system
+ * as a SELinux object managers.
+ *
+ * audit_fd - The fd returned by audit_open
+ * type - type of message, ex: AUDIT_USER_AVC
+ * message - the message being sent
+ * hostname - the hostname if known
+ * addr - The network address of the client
+ * dbuser - The name of database user
+ *
+ * It returns the sequence number which is > 0 on success or <= 0 on error.
+ */
+int audit_log_database_message(int audit_fd, int type, const char *message,
+			const char *hostname, const char *addr, const char *dbuser)
+{
+	char buf[MAX_AUDIT_MESSAGE_LENGTH];
+	char addrbuf[INET6_ADDRSTRLEN];
+	int retval;
+
+	if (audit_fd < 0)
+		return 0;
+
+	if (hostname && *hostname == '\0')
+		hostname = NULL;
+	addrbuf[0] = '\0';
+
+	if (addr == NULL || strlen(addr) == 0)
+		_resolve_addr(addrbuf, hostname);
+	else
+		strncat(addrbuf, addr, sizeof(addrbuf)-1);
+
+	if (dbuser && *dbuser == '\0')
+		dbuser = NULL;
+
+	snprintf(buf, sizeof(buf),
+		 "%s: (dbuser=%s, hostname=%s, addr=%s)",
+		 message,
+		 dbuser ? dbuser : "?",
+		 hostname ? hostname : "?",
+		 addr ? addr : "?");
+
+	errno = 0;
+	retval = audit_send_user_message(audit_fd, type, REAL_ERR, buf);
+	if (retval == -EPERM && getuid != 0) {
+		syslog(LOG_ERR, "Can't send to audit system: %s %s",
+		       audit_msg_type_to_name(type), buf);
+		return 0;
+	}
+
+	if ((retval < 1) && errno == 0)
+		errno = retval;
+
+	return retval;
+}
+
+/*
+ * This function will log a message to the audit system using a predefined
  * message format. This function should be used by all console apps that do
  * not manipulate accounts or groups.
  *

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[John Dennis]

KaiGai Kohei wrote:
> Hello,
>
> I'm a developer of SE-PostgreSQL which is an enhancement of
> database security using SELinux. It enables to apply the
> security policy of the operating system on accesses to
> database objects also.
> It makes an access control decision and audit messages, but
> these are not written out to system audit mechanism.
>
> I believe our preferable behavior is the system audit collects
> all the audit messages come from SELinux, not a logfile of
> PostgreSQL.
>
> Currently, the audit-libs has an interface to write a message
> come from userspace avc, but some of parameter is not suitable
> for the reference monitor in database management system.
>   
In the past it has been stated the kernel audit system is not
appropriate for general application logging because the kernel audit
system is not easily extensible and is not the place to log general
application data. While it is true the kernel audit system does allow
for some user level application logging by design and intention it is
constrained to select events deemed worthy of exception.

There is a new project called IPA (Identity, Policy, Audit) under
development. IPA v1 has been released, but the initial v1 release
focused only on the "I" part of IPA. In v2 we plan on filling out the
"P" and "A" parts. One of the things we're introducing for the Audit
component is a library called ELAPI (Event Logging API) which allows
applications to generate logging event data which is recursively
structured with key/value pairs (which can also be reformatted into
traditional strings). The library is capable of "dispatching" the
structured events to a variety of destination "sinks" (i.e. syslog,
file, IPA central logging repository, etc.). The destination sink
processing is accomplished with loadable plugin's so it should be easy
to to support any destination you want once you start utilizing the
ELAPI to log information. We had been planning on adding the kernel
audit system as a possible destination sink until the philosophy in the
above paragraph was pointed out to us.

ELAPI can be installed independent of IPA. I just went looking for
external documentation on ELAPI but it appears as though the ELAPI
documentation is only on a non-public wiki at the moment. I will try to
get that issue fixed shortly. ELAPI is still in development, although I
would say it's reaching the point of an alpha release.

Thus you may want to consider ELAPI for logging Secure Postgresql
messages and we would be interested in having you as a third party
review and exercise the library.

-- 
John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

Re: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Matthew Booth wrote:
> KaiGai Kohei wrote:
>> Hello,
>>
>> I'm a developer of SE-PostgreSQL which is an enhancement of
>> database security using SELinux. It enables to apply the
>> security policy of the operating system on accesses to
>> database objects also.
>> It makes an access control decision and audit messages, but
>> these are not written out to system audit mechanism.
>>
>> I believe our preferable behavior is the system audit collects
>> all the audit messages come from SELinux, not a logfile of
>> PostgreSQL.
>>
>> Currently, the audit-libs has an interface to write a message
>> come from userspace avc, but some of parameter is not suitable
>> for the reference monitor in database management system.
>>
>> This patch adds a new interface as follows:
>>     int audit_log_database_message(int audit_fd, int type,
>>                                    const char *message,
>>                                    const char *hostname,
>>                                    const char *addr,
>>                                    const char *dbuser);
>>
>> It is differ from audit_log_user_avc_message() in the point of
>> a new parameter of dbuser, instead of tty and uid.
>> I don't think these are meaningful information for DBMS, but
>> we would like to record what database user invokes this audit
>> record.
> 
> A few points:
> 
> When I have tried to use this mechanism in the past I have found the
> existing proliferation of user messages types confusing. If possible,
> please don't add a new custom message to the library. Instead, maybe it
> would be better to recognise that there will be continue to be new and
> unanticipated uses for structured audit data, and provide an api which
> allows that to be expressed.

What I would like to audit is AUDIT_USER_AVC type message, not a new
custome message type. But the current interface does not allow to
record some of meaningful information.
So, it was necessary to propose a new audit_log_database_message().
Perhaps, it might be misnamed. If confusable, it is possible to rename
it something like audit_log_db_avc_message().

> While where may be no tty as such, the idea is still meaningful.
> Specifically, one of the first things an auditor will want to know is
> where the user who performed a particular action logged on from. If you
> have that information, you should include it in the audit record.

In this case, all the audit record has same tty which is used by
the server process, independent from the client who performed a
particular action. :(

> A concept of a session ID would probably have meaning in this context.
> If you have one, or can create one, please include it in all messages,
> including login messages.

When a database client connects to the server via TCP/IP, we don't have
any valid session id. In addition, the server does not have a method to
know what session id is used for the client logged in.

> Lastly, please no freeform text! It should be possible to determine
> everything relevant about an event without looking at freeform text.

Yes, the expected style is same as ones for audit_log_user_avc_message(),
without any freedom text. The most significant purpose is to allow users
to use utilities such as audit2allow.

> I look forward to playing with this :)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>