Difference between revisions of "Row-security"

From PostgreSQL wiki
Jump to: navigation, search
(Considerations)
Line 3: Line 3:
 
This page is for discussion of implementing RLS in PostgreSQL.
 
This page is for discussion of implementing RLS in PostgreSQL.
  
== Previous discussion of RLS in PG ==
+
== Discussions of RLS in PG ==
 +
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01095.php Thread on -hackers]
 
* [http://it.toolbox.com/blogs/database-soup/thinking-about-row-level-security-part-1-30732 Josh Berkus on RLS in PG, Part 1]
 
* [http://it.toolbox.com/blogs/database-soup/thinking-about-row-level-security-part-1-30732 Josh Berkus on RLS in PG, Part 1]
 
* [http://it.toolbox.com/blogs/database-soup/thinking-about-row-level-security-part-2-30757 Josh Berkus on RLS in PG, Part 2]
 
* [http://it.toolbox.com/blogs/database-soup/thinking-about-row-level-security-part-2-30757 Josh Berkus on RLS in PG, Part 2]
Line 15: Line 16:
 
* [http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_implementmls4row.htm IBM/DB2 RLS Documentation]
 
* [http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_implementmls4row.htm IBM/DB2 RLS Documentation]
 
* Other?
 
* Other?
 +
 +
== Related but independent issues ==
 +
* Fixing leaks of data through "security" views, specifically, a user can define a function and convince the planner to run that function
 +
on all records of a table under a view, even though the view has a 'WHERE' clause which should prevent the user from seeing every row.
  
 
== Use Cases ==
 
== Use Cases ==

Revision as of 17:51, 14 December 2009

Row-Level Security

This page is for discussion of implementing RLS in PostgreSQL.

Discussions of RLS in PG

Articles/Documentation of existing RLS implementations

Related but independent issues

  • Fixing leaks of data through "security" views, specifically, a user can define a function and convince the planner to run that function

on all records of a table under a view, even though the view has a 'WHERE' clause which should prevent the user from seeing every row.

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