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
securitylabel support, so it assumes pg_description stores security label of tables/columns instead. - No default
labelingsupport, so we have to label tables/columns prior to accesses by hand. - No access control decision cache. -
andso many limitations now...
Example usage: [kaigai@saba ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [kaigai@saba ~]$ psql
postgrespsql (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:s0tclass=db_table name=t1 LOG: SELinux: allowed { select }
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023tcontext=system_u:object_r:sepgsql_table_t:s0
tclass=db_columnname=t1.a LOG: SELinux: allowed { select }
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023tcontext=system_u:object_r:sepgsql_table_t:s0
tclass=db_columnname=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.
Itmeans the 'c' of categories. In this example, the client has privileges to access whole of the categories from c0
toc1023, so SELinux does not prevent accesses.
Then, let's try to log in with more restricted privileges.
[kaigai@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:c0tclass=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
categoriesor 'c1' category. Please remind 't2.x' was labeled as '...:c0', so the client is not allowed to reference
thecolumn. Then, the next query accesses only table 't1' and column 't1.y'. It does not contains any objects with
accessviolations, 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@ak.jp.nec.com>
