Re: SE-PgSQL patch review - Mailing list pgsql-hackers

KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>   -- keep it smaller, and step-by-step enhancement

I'd prefer "smaller concept" rather than "smaller patch".

I think the philosophy of SE-PgSQL itself is ok,
but there are some issues in the design and implementation:

==== No interaction with existing features ====
* SE-PgSQL injects security-context-based access control, but there are no interaction between it and the existing
role-basedaccess control.
 

* SE-PgSQL introduces concept of "security context", but there are no interaction between it and the existing
context-relatedfeatures. (ex. pg_hba.conf and Application name patch)
 

This is just an idea, but how about implementing context-based access
control based on role-based ACL? We will not use security context directly
for access control, but it forbid to use ROLEs in some conditions.
An example of implementation image is:
 =# ALTER ROLE role VALID ON SECURITY CONTEXT '...'

For example, this could allow us to modify rows only with a particular
application, only from particular machine, and only in particular hour.
Since we've already supported object- and column-level ACL, I think
we can the same capability of the patch using security-context-to-role
mapper. Or, is it not ideal in the policy of SELinux?

==== Postgres is not prepared to receive SE-PgSQL ====
We depend on superuser too heavily. As KaiGai-san mentioned, we use
"if (superuser())" instead of ACL in some places. It is a bad manner.
We should centralize access control in one module (maybe aclcheck.c),
and SE-PgSQL should be implemented only in the module.

If possible, it might be good for SE-PgSQL to replace all of the
role-based access control layer in postgres because it is hard for
users to maintain both Postgres ROLEs and SELinux settings consistently.
Do we need pluggable ACL layer before accepting SE-PgSQL?

==== Need to reconsider row-level security control ====
Row-level security control is excluded from the patch, but we'd better
also considering it at first. You mentioned as:

> In SELinux model, massive number of objects shares a limited number of
> security context (e.g more than 100 tables may have a same one)

but I'm not sure what application do you suppose. For example,
if we protect web application from SQL injection attacks, the
password column for each row can be read only from the end user
represented by the row. The number of security labels will be same
as the number of end users (= rows).

==== Actual benefits of SE-PgSQL ====
SE-PgSQL will be committed step-by-step -- but could you explain which step
can solve which problem in the real world? Imagine that SQL injections,
measure for SOX Act, divulgation of personal information, .... They are
security holes in terms of a whole application, but not a hole in terms of
database, because database cannot always distinguish between legal and
illegal data access (ex. correction of wrong data vs. rigging of benefits).

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center