Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

Ron Mayer wrote:
> Stephen Frost wrote:
>> And, just to go full circle, row-level access controls are exactly what
>> the other enterprise RDBMSs have and is what is used in these security
>> circles today.  One of the major issues, as I understand it, is to be
>> able to use stock applications with multiple security levels where the
>> application doesn't know (or care about) the security level.  Doing that
>> through views and partitions and triggers and whatnot for each and every
>> application that is run on these systems will be a big hurdle to those
>> users, if it ends up being workable at all.
> 
> That seems to me to be a shortcoming of the partition system and a good
> TODO for the future partitioning improvements.
> 
> Why shouldn't be just as easy to make sure a row ends up in the
> right partition as opposed to making sure it's tagged with right
> row-level ACLs.
> 

In reality it isn't, unless postgres won't mind thousands of partitions being 
made. In the military/gov implementations BLP lets you have hierarchical levels 
and non-hierarchical categories. Since I linked to an article about it upthread 
I assumed everyone participating was familiar but perhaps not. Typically there 
are 3 levels, unclass, secret, top secret. In addition to those 3 levels there 
may be a few, hundreds or even thousands of categories. Those categories apply 
to each of the levels so if you are using 1000 categories you have 3*1000 
possible BLP labels. On top of that SELinux has users, roles and types, which 
are all also multiplied.

There is a reason we don't do things like have 3 filesystems, one for unclass, 
one for secret and one for top secret.

Partitions/views may be a good way to implement row-level access control when 
there are a few different options but they won't necessarily be known ahead of 
time. We don't want to encode policy logic in to the database itself, that is 
why we have a separate security server that handles the policy. The system 
should scale to any number of contexts that are available on the system.

Relabeling with partitions (that is, moving things from one partition to 
another) seems to be handled with triggers, which is inconvenient to the 
application developers but also devastating to the security system (unless you 
can map triggers back to who did the operation that caused them), and managing 
partitions on dozens or hundreds of tables and moving data between them in those 
tables seems at the very least challenging.

I also have questions concerning partitions. Perhaps someone wants to use 
partitions for a functional purpose (eg., to split log entries by month/year). 
What would be the affect of concurrently using partitions to split security 
contexts out?

Nonetheless, this conversation seems moot now that Tom has walled off and won't 
even discuss row-level access controls.

Cheers.