Cell-Level security

Greetings,

* Andrew Alsup (bluesbreaker@gmail.com) wrote:

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?

I'm certainly interested in this as well but I'd really want to see it
as a built-in addition on top of the existing policy system, in some
fashion. I've thought a bit about how that might work and I'm certainly
open to suggestions, but I don't think an hstore would be the way to go.
I would think something more akin to a pg_attribute for pg_policy would
allow a great deal of flexibility; in particular, I'm thinking that this
system could be used to also provide data masking, if the user so
wishes, instead of just "you see it or you don't."

As for where to hook this in, the rewriter seems like a pretty good
place as that's where RLS is happening but I'll admit that I have some
concerns about what we'll need to do to make sure that we don't end up
with data leaks when users are writing their own data-masking functions
to use in these policies.

Thanks!

Stephen