Re: How to get SE-PostgreSQL acceptable

Sorry for top-posting and avoiding to paste online doc URL.

Joshua, you sound like you're missing an important point. Sorry for
misunderstanding if that's not true.

Partitioning is supported in a way that a query does not need to know
about it, be it a SELECT, INSERT, UPDATE or DELETE. And 8.4 onwards,
some more.

What Tom is talking about is adding support for discarding partitions
based on GRANTed rights rather than WHERE clauses.

No application rewrite.

Columns obfuscating remains to be cared of: what about allowing views
as partitions?

HTH, regards,
--
dim

Le 28 janv. 09 à 19:49, Joshua Brindle <method(at)manicmethod(dot)com> a
écrit :

> 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.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers