[RFC] PostgreSQL Access Control Extension (PGACE) - Mailing list pgsql-hackers

As I announced alpha version of SE-PostgreSQL about one month ago,
I'm working for development of a security facility integrated with
secure operating system.

It provides database users fine grained mandatory access control
including row and column level one, and integration with operating
system security policy.

This concept may have applicability to other secure operating system
such as Trusted Solaris. Just after the announcement, Sun.com's people
were interested in SE-PostgreSQL works, and contacted me.
They also want to implement a similar functionality on their operating
system using Trusted Extension (TX).

We got an agreement that a common framework like LSM will be useful
to implement and maintain those secure facilities.

I want to have a discussion and get feedbacks about this idea from
PostgreSQL developers.

----------
The framework named PGACE(PostgreSQL Access Control Extension).
It provides two major facilities. One is hooks on some strategic points.
The other is a functionality to associate a tuple with its security
attribute.

Any hooks is defined as a static inline functions in "security/pgace.h".
They give no effect, if no security facilities are configured.
If SELinux support is enabled via configure script, those definitions
are overwritten by "security/sepgsql.h", and the hooks calls actual
SE-PostgreSQL implementation to provide MAC(mandatory access control).

Those hooks are deployed on the some strategic points of PostgreSQL such as
simple_heap_insert(), PortalStart() and so on.

You can get all the definition of pgace.h and sepgsql.h from the following URL:
http://sepgsql.googlecode.com/svn/trunk/src/include/security/

The later functionality enables to associate a tuple with security attribute.
It adds a new field (t_security) with Oid type into HeapTupleHeaderData
structure. The t_security can persistently hold a Oid of pg_security new
system catalog. The pg_security has a combination of Oid value and security
attribute with text representation.

Database users can refer the attribute via new system column.
When SQL query tries to refer this attribute via the system column,
PGACE lookups pg_security system column to get a tuple which has same oid
compared to t_security value of its HeapTupleHeaderData.
It's implemented as input/output handler of new security_label type.

The name of system column is defined in pg_config.h.in.
In SELinux case, it's named "security_context". This system column is
writable via UPDATE or INSERT statement, to enables relabeling.

Because most of security attribute shares same text representation, this
implementation works effectively and economically.

As you know, PostgreSQL handles any database object as a tuple stored in
system catalogs. So, this concept may have applicability to any kind of
database object like table, column and procedure.
----------

I hope that SE-PostgreSQL and PGACE are merged into future upstreamed
PostgreSQL and we can turn on/off by configure option without any patch.

I believe any comments and feedbacks are so helpful to indicate the
direction of our development with an approach which is acceptable by
PostgreSQL development community.

Thanks,

* Reference
The full set of patch is a bit large to post the list directly. (6.7KL)

You can checkout the source code from the following URL: http://code.google.com/p/sepgsql/source
You can get the patch for SE-PostgreSQL based on PGACE from the following URL:
http://sepgsql.googlecode.com/files/sepostgresql-8.2.3-226.patch(against to the stable postgresql-8.2.3)
 
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>