Difference between revisions of "Row-security"

From PostgreSQL wiki
Jump to: navigation, search
(Considerations)
(Considerations)
Line 63: Line 63:
 
** With RLS
 
** With RLS
 
** Without RLS
 
** Without RLS
 +
** The page.16 of [http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf LAPP/SELinux slides] shows a pgbench comparison between pgsql-8.4.1 vs SE-PostgreSQL with RLS.
 +
*** It has 2-4% of performance tradeoff depending on database size.
 +
 
* Integration with external security manager (eg: SELinux, SMACK)
 
* Integration with external security manager (eg: SELinux, SMACK)
 
** The way to manage security label of tuples
 
** The way to manage security label of tuples

Revision as of 08:39, 14 December 2009

Row-Level Security

This page is for discussion of implementing RLS in PostgreSQL.

Previous discussion of RLS in PG

Articles/Documentation of existing RLS implementations

Use Cases

  • PCI Compliant implementations
  • Classified Environments
  • Other?

Components of an implementation

  • Grammar
  • Catalog
  • Storage
  • Planner (necessary?)
  • Executor
  • Other?

Issues

  • Covert Channel
    • If we tries to insert a value which conflicts to PK constraint, we can estimate existence of invisible PK from errors.
    • Ditto, for FK. If we tries to remove a FK tuple referenced by invisible PK, we can estimate existence of invisible PK from errors.
    • We shall not care about this issue. Prior commercial database products with row-level security also don't support such a restriction due to the technical difficulty.
  • Order to evaluate row level policy
    • User defined function can have lower cost than row-level security policy functions. In this case, user defined (maybe malicious) function can be invoked with arguments which refers invisible tuples.
    • There are same issue in VIEWs.
    • Row-level policy function/clause has to be evaluated prior to any user given quals.
  • TRUNCATE statement
    • It removes all the tuples in a certain table, but it may contain unremovable tuples due to the row-level policy.
    • idea: Scan the table to check no tuples are unremovable earlier than TRUNCATE. The "abort-mode" can be used we noted in FK-constraint.
    • idea: Disallow all the TRUNCATE, if the table has row-level policy.
  • COPY TO statement
    • We also need to apply row-level policy on COPY TO statement to avoid information leaks.
    • idea: COPY tblname TO xxx; can be replaced by COPY (SELECT * FROM tblname) TO xxx;.
  • Table inheritance
    • What policy should be applied on the parent and child relations.
    • idea: Also copy row-level policies from the parent tables.
  • Foreign Key constraint
    • FK constraint is
    • idea: We can provide two modes: The first is filter-mode, the second is abort-mode.
      • filter-mode: A normal mode. Row-level policy is evaluated earlier than user given condition, and returns false, if violated.
      • abort-mode: A special internal mode. Row-level policy is evaluated after all the condition, and raises an error, if violated. The condition shall be evaluated earlier than row-level policy, the query has to be trusted. Such as queries in FK constraint.

Considerations

  • Performance
    • With RLS
    • Without RLS
    • The page.16 of LAPP/SELinux slides shows a pgbench comparison between pgsql-8.4.1 vs SE-PostgreSQL with RLS.
      • It has 2-4% of performance tradeoff depending on database size.
  • Integration with external security manager (eg: SELinux, SMACK)
    • The way to manage security label of tuples