From: | Andrew Alsup <bluesbreaker(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Cell-Level security |
Date: | 2018-12-19 20:19:54 |
Message-ID: | CADOZ7s7xz=YF=Dwf7inOsnzNjkaj4=B84psqo+mm_09bpmothg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Contrary to popular understanding, in classified environments it is common
to have data marked with a variety of combinations that make it difficult
to create roles and labels that match the various permutations. As a simple
example, a document could be classified as follows:
Releasable to US citizens with a secret clearance OR Canadian citizens with
a top-secret clearance OR Australian citizens with a top-secret clearance.
I am developing an extension that exposes a function, callable from a
PostgreSQL RLS policy which supports Accumulo-style visibility expressions.
Using the example above, the record might contain the following security
label expression:
(S&US)|(TS&CAN)|(TS&AUS)
A little more info on Accumulo-style expressions can be found here:
https://accumulo.apache.org/1.6/apidocs/org/apache/accumulo/core/security/ColumnVisibility.html
Although I still have more testing to do, things are working well, and
there are some options about where the RLS policy function can pull the
authorizations from when determining visibility. Currently JWT tokens (via
set_config) are supported.
I'm wondering how feasible a cell-level security implementation would be.
My thought is that by using an hstore column, a table could opt-in to row-
and cell-level security, by having the hstore track the visibility of any
or all columns in the row.
| id | fname | lname | vis(hstore) |
|----|-------|-------|---------------------|
| 1 | Bob | Umpty | vis[_row_] = 'U' |
| | | | vis[fname] = 'S' |
| | | | vis[lname] = 'U&USA'|
|----|-------|-------|---------------------|
| 2 | Alice | Skwat | vis[_row_] = 'S' |
|----|-------|-------|---------------------|
For tables that have the vis(hstore) column, a query rewrite could ensure
that column references are wrapped in a visibility check, akin to using a
CASE statement within a SELECT.
I've begun studying the call chain from parser to planner to rewrite to
executor. I'm not sure where the best place would be to perform this work.
I'm thinking the query-rewrite might work well. Thoughts?
From | Date | Subject | |
---|---|---|---|
Next Message | mkondle | 2018-12-19 20:24:29 | Postgres Replication Issue |
Previous Message | David Steele | 2018-12-19 20:19:04 | Re: Remove Deprecated Exclusive Backup Mode |