Re: How to get SE-PostgreSQL acceptable

Joshua Brindle wrote:
> 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,

Help me understand this.

It seems to me exactly as easy/hard to make sure that the secret and
top-secret rows are put into their appropriate partitions, as it is
to make sure that the secret and top-secret rows are tagged with the
right row-level-access-info.

If the idea is that the top-secret-row-inserter magically forces the
row-level tag "top-secret" it seems just as easy if the top-secret
row-inserter only has write permission to the "top-secret" partition
and not the others.

If the idea is that the less-secret-reader can't read rows
tagged "top-secret" it seems just as easy if the less-secret-reader
has no read access on the top-secret partition.

At first glance, partition level seems quite a bit easier to
manage in all the cases I can think of immediately.

> partitions don't help because, once again, the application would be
> making the determination about which partition to query. For mandatory

I think that's not true. I would hope that the application
queries the master table, and the SEPostgres ACLs prevent
any data coming from the inappropriate partitions.

> 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

Why not? It seems one can define the user with read access on the
partition with secret rows and read/write on top-secret rows.
Queries done on the master partition should get the data out in
a transparent way.

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

ISTM we need to have a discussion of how partitioned tables
work - and what the postgres roadmap is.

If they can't yet, I think they should.

>> 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.

AFACT there's nowhere near a consensus that it should be discarded (or
accepted); but rather that if the project can be split into two phases
parts of it could go in sooner.

There seems to be much less debate about the column/table/partition
level MAC parts.

Once those get in, I think the next valuable discussion would be
whether the fine-grained access control is best achieved through
improving the partition system or by adding the row-level acls as proposed.