Cell-Level security

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?

Responses

Browse pgsql-hackers by date

  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