Difference between revisions of "Row-security"

From PostgreSQL wiki
Jump to: navigation, search
Line 2: Line 2:
  
 
This page is for discussion of implementing RLS in PostgreSQL.
 
This page is for discussion of implementing RLS in PostgreSQL.
 +
 +
== Prerequisites ==
 +
- Before we can try to tackle row-level security generally, using labels or not, we need to fix the issues with data leaks in views.
 +
- This issue is summarized as: an untrusted user can define a function which stores all information it is presented, then query a view using that function in a way which will convince the planner to send every row of the underlying table to the function, thus leaking data in the table which the view was intended to prevent.
 +
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg01346.php Thread on information leak due to views]
 +
* [http://archives.postgresql.org/pgsql-hackers/2009-02/msg00861.php Earlier discussion of view leak]
  
 
== Discussions of RLS in PG ==
 
== Discussions of RLS in PG ==
Line 16: Line 22:
 
* [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.
 
Need link to previous discussion about views (specifically, Heikki wrote about this over the summer..)
 
  
 
== Use Cases ==
 
== Use Cases ==
Line 28: Line 29:
  
 
== Components of an implementation ==
 
== Components of an implementation ==
* Grammar
+
* Overview
* Catalog
+
** Allow the query to be modified, prior to being passed to the planner, in such a way that the rows returned will be those the user is authorized for
* Storage
+
** This depends on being able to tell the planner that this filter must be done, in some way, prior to user-defined functions being called
* Planner (necessary?)
+
** This issue is related to the VIEW leak described above.  Once that issue has been resolved, this should be pretty straight-forward to implement
* Executor
+
* Grammar for catalog updates/changes; user-interface for specifying how RLS is to be done
 +
* Catalog changes for storing RLS information
 +
* Storage - Could this just be a regular column in the table?  It would be good to avoid changing the header or creating a system column for this.
 +
** We would need to track, in some fashion, the "security" column in the catalog, perhaps as a flag on pg_attribute, or a 'security_attnum' in pg_class, etc.
 +
* Planner updates to enforce the filter based on RLS- this can't be done till after we deal with the issue with VIEWs
 +
* Executor changes may not be required..  but how to deal with stored plans?  Use invalidation if anything changes with regard to RLS?
 
* Other?
 
* Other?
  
 
== Issues ==
 
== Issues ==
 
* Covert Channel
 
* Covert Channel
** If we tries to insert a value which conflicts to PK constraint, we can estimate existence of invisible PK from errors.
+
** If we try to insert a value which violates a PK constraint, we can assume existence of invisible PK from the error.
** Ditto, for FK. If we tries to remove a FK tuple referenced by invisible PK, we can estimate existence of invisible PK from errors.
+
** The same issue exists in a Foreign Key relationship situation
** 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.
+
** Other databases with row-level security don't address this issue, so it's unclear if we really need to (reference?)
 +
** In any case, this isn't something we need to address in our initial RLS implementation
  
 
* Order to evaluate row level policy
 
* 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.
+
** Addressed above with regard to views, once we solve that, this will be handled
** There are same issue in VIEWs.
 
** Row-level policy function/clause has to be evaluated prior to any user given quals.
 
  
 
* TRUNCATE statement
 
* TRUNCATE statement
** It removes all the tuples in a certain table, but it may contain unremovable tuples due to the row-level policy.
+
** TRUNCATE is expected to be fast.
** idea: Scan the table to check no tuples are unremovable earlier than TRUNCATE. The "abort-mode" can be used we noted in FK-constraint.
+
** If the user does not have rights to remove all rows from the table regardless of row-level policy, then any TRUNCATE must be denied.
** idea: Disallow all the TRUNCATE, if the table has row-level policy.
+
** Turning TRUNCATE (a PostgreSQL extension which is not in the SQL spec anyway) into a DELETE FROM doesn't make sense.
  
 
* COPY TO statement
 
* COPY TO statement

Revision as of 02:49, 15 December 2009

Row-Level Security

This page is for discussion of implementing RLS in PostgreSQL.

Prerequisites

- Before we can try to tackle row-level security generally, using labels or not, we need to fix the issues with data leaks in views. - This issue is summarized as: an untrusted user can define a function which stores all information it is presented, then query a view using that function in a way which will convince the planner to send every row of the underlying table to the function, thus leaking data in the table which the view was intended to prevent.

Discussions of RLS in PG

Articles/Documentation of existing RLS implementations

Use Cases

  • PCI Compliant implementations
  • Classified Environments
  • Other?

Components of an implementation

  • Overview
    • Allow the query to be modified, prior to being passed to the planner, in such a way that the rows returned will be those the user is authorized for
    • This depends on being able to tell the planner that this filter must be done, in some way, prior to user-defined functions being called
    • This issue is related to the VIEW leak described above. Once that issue has been resolved, this should be pretty straight-forward to implement
  • Grammar for catalog updates/changes; user-interface for specifying how RLS is to be done
  • Catalog changes for storing RLS information
  • Storage - Could this just be a regular column in the table? It would be good to avoid changing the header or creating a system column for this.
    • We would need to track, in some fashion, the "security" column in the catalog, perhaps as a flag on pg_attribute, or a 'security_attnum' in pg_class, etc.
  • Planner updates to enforce the filter based on RLS- this can't be done till after we deal with the issue with VIEWs
  • Executor changes may not be required.. but how to deal with stored plans? Use invalidation if anything changes with regard to RLS?
  • Other?

Issues

  • Covert Channel
    • If we try to insert a value which violates a PK constraint, we can assume existence of invisible PK from the error.
    • The same issue exists in a Foreign Key relationship situation
    • Other databases with row-level security don't address this issue, so it's unclear if we really need to (reference?)
    • In any case, this isn't something we need to address in our initial RLS implementation
  • Order to evaluate row level policy
    • Addressed above with regard to views, once we solve that, this will be handled
  • TRUNCATE statement
    • TRUNCATE is expected to be fast.
    • If the user does not have rights to remove all rows from the table regardless of row-level policy, then any TRUNCATE must be denied.
    • Turning TRUNCATE (a PostgreSQL extension which is not in the SQL spec anyway) into a DELETE FROM doesn't make sense.
  • 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