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: [kai...@saba ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [kai...@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. [kai...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
