1:11 a.m.
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(a)ak.jp.nec.com>
4:45 p.m.
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(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
5749
days inactive
5749
days old
linux-audit@lists.linux-audit.osci.io
1 comments
2 participants
participants (2)
-
John Dennis -
KaiGai Kohei