KaiGai Kohei <kai...@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-based access control. * SE-PgSQL introduces concept of "security context", but there are no interaction between it and the existing context-related features. (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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
