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>

2010/6/17 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> 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

This is a good start - I think with some cleanup this could be
committable, though probably it makes sense to wait until after we get
the security label infrastructure in. I suspect some code cleanup
will be needed; one thing I noticed off the top of my head was that
you didn't follow the usual style for installing hook functions in a
way that can accomodate multiple hooks. See contrib/auto_explain for
an example.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

(2010/06/17 21:59), Robert Haas wrote:
> 2010/6/17 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> 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
>
> This is a good start - I think with some cleanup this could be
> committable, though probably it makes sense to wait until after we get
> the security label infrastructure in. I suspect some code cleanup
> will be needed; one thing I noticed off the top of my head was that
> you didn't follow the usual style for installing hook functions in a
> way that can accomodate multiple hooks. See contrib/auto_explain for
> an example.
>
Thanks for your comments. I'll fix it later.

BTW, I have a question which community (PostgreSQL or SELinux) shall
eventually maintain the module, although PostgreSQL provides a set of
interfaces for access control modules?
I thought SELinux side (mainly I and NEC) will maintain the sepgsql
module being suitable for the interfaces.

If we need another proof-of-concept module independent from selinux
for regression test, at least, it is not a tough work.

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

2010/6/17 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (2010/06/17 21:59), Robert Haas wrote:
>> 2010/6/17 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> 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
>>
>> This is a good start - I think with some cleanup this could be
>> committable, though probably it makes sense to wait until after we get
>> the security label infrastructure in.  I suspect some code cleanup
>> will be needed; one thing I noticed off the top of my head was that
>> you didn't follow the usual style for installing hook functions in a
>> way that can accomodate multiple hooks.  See contrib/auto_explain for
>> an example.
>>
> Thanks for your comments. I'll fix it later.
>
> BTW, I have a question which community (PostgreSQL or SELinux) shall
> eventually maintain the module, although PostgreSQL provides a set of
> interfaces for access control modules?
> I thought SELinux side (mainly I and NEC) will maintain the sepgsql
> module being suitable for the interfaces.
>
> If we need another proof-of-concept module independent from selinux
> for regression test, at least, it is not a tough work.

I had thought perhaps it would end up as a contrib module, but there
are other options.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company