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)
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?
