modular se-pgsql as proof-of-concept

I tried to implement a modular se-pgsql as proof-of-concept, using the DML
permission check hook which was proposed by Robert Haas.

At first, please build and install the latest PostgreSQL with this
patch to add a hook on DML permission checks.
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01095.php

Then, check out the modular se-pgsql, as follows:
% svn co http://sepgsql.googlecode.com/svn/trunk/ sepgsql

Build and install:
% cd sepgsql
% make
% su -c 'make install'

Setting it up.
% initdb -D $PGDATA
% vi $PGDATA/postgresql.conf
---> add 'sepgsql' for the 'shared_preload_libraries'
% pg_ctl -l /path/to/logfile

Limitations:
- It does not check anything except for regular DML statements
(SELECT, INSERT, UPDATE and DELETE).
- No security label support, so it assumes pg_description stores
security label of tables/columns instead.
- No default labeling support, so we have to label tables/columns
prior to accesses by hand.
- No access control decision cache.
- and so many limitations now...

Example usage:
[kaigai(at)saba ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[kaigai(at)saba ~]$ psql postgres
psql (9.0beta2)
Type "help" for help.

postgres=# CREATE OR REPLACE FUNCTION sepgsql_getcon() RETURNS text
AS 'sepgsql','sepgsql_getcon' LANGUAGE 'C';
CREATE FUNCTION
postgres=# SELECT sepgsql_getcon();
sepgsql_getcon
-------------------------------------------------------
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

=> It means it can obtain security context of the peer process correctly.
Please confirm it is same as the result of 'id -Z'.

postgres=# CREATE TABLE t1 (a int, b text);
CREATE TABLE
postgres=# CREATE TABLE t2 (x int, y text);
CREATE TABLE

=> No DDL support now, so SELinux does not prevent anything.

postgres=# INSERT INTO t1 VALUES (1, 'aaa'), (2, 'bbb'), (3, 'ccc');
ERROR: SELinux: security policy violation

=> Because no labels are assigned on the table and columns, SELinux
raises an access control violation error.

postgres=# COMMENT ON TABLE t1 IS 'system_u:object_r:sepgsql_table_t:s0';
COMMENT
postgres=# COMMENT ON COLUMN t1.a IS 'system_u:object_r:sepgsql_table_t:s0';
COMMENT
postgres=# COMMENT ON COLUMN t1.b IS 'system_u:object_r:sepgsql_table_t:s0';
COMMENT

=> In this stage, it uses pg_description to store the security label of
database objects, instead of the upcoming facilities.

postgres=# INSERT INTO t1 VALUES (1, 'aaa'), (2, 'bbb'), (3, 'ccc');
INSERT 0 3

=> Because these are labeled correctly, SELinux allows to execute INSERT
statement on the table/columns.

postgres=# SET client_min_messages = LOG;
SET
postgres=# SET sepgsql_debug_audit = ON;
SET
postgres=# SELECT * FROM t1;
LOG: SELinux: allowed { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sepgsql_table_t:s0 tclass=db_table name=t1
LOG: SELinux: allowed { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sepgsql_table_t:s0 tclass=db_column name=t1.a
LOG: SELinux: allowed { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sepgsql_table_t:s0 tclass=db_column name=t1.b
a | b
---+-----
1 | aaa
2 | bbb
3 | ccc
(3 rows)

=> We can observe what permissions were evaluated using 'sepgsql_debug_audit',
even if required permissions were allowed.
('denied actions' will be logged in the default.)

postgres=# CREATE TABLE t2 (x int, y text);
CREATE TABLE
postgres=# COMMENT ON TABLE t2 IS 'system_u:object_r:sepgsql_table_t:s0';
COMMENT
postgres=# COMMENT ON COLUMN t2.x IS 'system_u:object_r:sepgsql_table_t:s0:c0';
COMMENT
postgres=# COMMENT ON COLUMN t2.y IS 'system_u:object_r:sepgsql_table_t:s0:c1';
COMMENT
postgres=# INSERT INTO t2 VALUES (1,'xxx'), (2,'yyy');
INSERT 0 2
postgres=# SELECT sepgsql_getcon();
sepgsql_getcon
-------------------------------------------------------
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)
postgres=# SELECT * FROM t2;
x | y
---+-----
1 | xxx
2 | yyy
(2 rows)

=> Note that ':c0' was appended on the security label of t2.x, and ':c1' was
appended on the security label of t2.y. It means the 'c' of categories.
In this example, the client has privileges to access whole of the categories
from c0 to c1023, so SELinux does not prevent accesses.

Then, let's try to log in with more restricted privileges.

[kaigai(at)saba ~]$ runcon -l s0:c1 psql postgres
psql (9.0beta2)
Type "help" for help.

postgres=# SET client_min_messages = LOG;
SET
postgres=# SELECT sepgsql_getcon();
sepgsql_getcon
----------------------------------------------
unconfined_u:unconfined_r:unconfined_t:s0:c1
(1 row)

postgres=# SELECT * FROM t2;
LOG: SELinux: denied { select } scontext=unconfined_u:unconfined_r:unconfined_t:s0:c1 tcontext=system_u:object_r:sepgsql_table_t:s0:c0 tclass=db_column name=t2.x
ERROR: SELinux: security policy violation
postgres=# SELECT y FROM t2;
y
-----
xxx
yyy
(2 rows)

=> It tries to connect to PostgreSQL with more restricted privileges.
It is allowed to access objects with no categories or 'c1' category.
Please remind 't2.x' was labeled as '...:c0', so the client is not
allowed to reference the column.
Then, the next query accesses only table 't1' and column 't1.y'.
It does not contains any objects with access violations, so SELinux
does not prevent anything.

postgres=# COPY t2 TO stdout;
1 xxx
2 yyy

=> Of course, COPY TO/FROM is not hooked, so SELinux cannot prevent
anything. It is an expected behavior.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>