Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei <kaigai@kaigai.gr.jp>]

I intend to filter the result set by appending avc_has_perm(...) condition
for each targeted table. I believe it is the most simple implementation
and it can utilize the optimizer of PostgreSQL.

>>> (A) select * from customer;
>>>
>>> (B) select * from customer where avc_has_perm(getpeercon(),
>>>                                               security_context,
>>>                                               DATABASE__SELECT);
> 
> A turns in to B via the proxy. Then the database does the avc_has_perm
> check as part of the query. An administrator would have more access via
> the policy. The proxy would not be discarding anything.

If we consider the modules in PostgreSQL as separated processes,
we may be able to say this mechanism the proxy.
But we cannot rewrite SQL statement outside the server process,
because PosgreSQL itself may rewrite the query tree internally.

The details are described in the following URL:
  Chapter 34. The Rule System
  http://www.postgresql.org/docs/8.1/static/rules.html

By the above reason, we must inject additional conditions of
SELinux after completion of query rewriting, and we cannot
have any option except the implementation within DBMS.

>> Then when you do a join of two tables with such configurations things would 
>> get even more interesting for the author of a proxy.
>>
>>> One could even use the proxy model within the same process space to
>>> manipulate the query as it enters the database server instead of hooking
>>> in to the database server at every access point.
>>>
>>> The bad part about this is that it makes for a less fine grained model
>>> than hooking at access points.
>> If you want to only control table access then things become much easier.

When we do a join of two tables, the joined virtual table are generated
from filtered two result set. All of its contains are allowed to select.

The result is same, even if a view was defined as a select statement
which do a join of multiple tables.

> like I said, "it makes for a less fine grained model"
> 
>>> One thing to think about is stored procedures and how those can be dealt
>>> with, triggers, etc. Without access control hooks triggers are much
>>> harder to deal with access control wise, as are stored procedures.

The stored procedure is a bit considerable.
Now I cannot conclude about its handling whether it's suitable for this solution.
More hacking to PostgreSQL is necessary. ;)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.