Re: How to get SE-PostgreSQL acceptable

Tom Lane wrote:
> Joshua Brindle <method(at)manicmethod(dot)com> writes:
>> I'm not sure how much it would cut to remove row level access
>> controls, but I do have some points here. To me, row level access
>> controls are the most important part, this is the feature that lets us
>> put secret and top secret data in the same table and use the clients
>> selinux context to decide what they can see,
>
> For me, the row-level access controls are really the sticking point.
> There is absolutely nothing you can say that will convince me that they
> don't break SQL in fundamental ways, and I also don't believe that it's
> going to be possible to implement them without a constant stream of bugs
> of omission and commission. (Those two points are not unrelated.)
>

This isn't going to be something that the vast majority of your users use. The
people that need them understand the ramifications of row filtering and the
absence of inaccessible rows won't be surprising.

> Now that you've admitted that you aren't trying to accomplish the
> equivalent sort of data hiding within the filesystem, the argument that

We apply access controls on reading and writing files, this is equivalent (in my
mind) to applying access controls on tuples, as they are the structured object
holding data (just like files).

> you have to have them seems fairly weak, certainly not strong enough to
> justify the costs. We have already touched on some ways that you can

The costs are nil for people who don't want this feature.

> accomplish similar goals with just table- and column-level access
> permissions, which are well understood and don't violate anyone's

I've already pointed out how table and column level access control don't provide
enough. Holding data of multiple classifications in a single table is something
of great concern. Unmodified applications need to be able to query out of a
table and get the data they are cleared to see. Column level access control
doesn't help because those same applications, of course, will need access to the
data in those columns.

Splitting data into different tables isn't an option in many cases because
applications aren't always configurable wrt to the database or tables they use.
Further, clients of multiple clearances should be able to use the same
application, and we can not trust the application to make the decision as to
which database or table is correct.

And even further, maintaining multiple sets of databases or tables that hold the
same kinds of information (and therefore have the same schema) is a maintenance,
backup and restoration issue.

> expectations. There's probably a need to twiddle our permissions rules
> for inheritance/partitioning cases, but that was already on the table
> anyway for other reasons.
>

partitions don't help because, once again, the application would be making the
determination about which partition to query. For mandatory access control that
we need in the kind of environments to work the application doesn't get to make
security relevant decisions, the database holds the data and needs to say who
can access it.

Further, partitioning isn't fine grained. I can't say user X can read secret
rows and read/write top secret rows and get that data out in a transparent way
(the applications would have to be aware of the partitions). Relabeling of data
also looks like a challenge with partitions (if I correctly understand how they
work).

> I could be persuaded to get behind a patch that does Peter's step #1
> (ie, use SELinux permissions as an additional filter for existing SQL
> permission checks). I don't believe I will ever think that row-level
> checks are a good idea; as long as those are in the patch I will vote
> against applying it.
>

We've already used postgresql in sensitive environments and had to make
compromises because of the lack of fine grained access control. We've been
telling customers for years that we hope postgresql will have said access
controls in the future and that it will help them solve many of the problems
they have.

We've been enthusiastic about the work KaiGai has been doing with respect to the
environments we operate in and it would be a shame for all that to be discarded.