Re: How to get SE-PostgreSQL acceptable

Tom Lane wrote:
> Joshua Brindle <method(at)manicmethod(dot)com> writes:
>> 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.
>
> Hmm. If that's the expected application environment then the patch as

It's one application environment, maybe not a common one but one I've seen.

> proposed has fatal performance problems anyway, for lack of a way to
> get rid of no-longer-referenced pg_security rows. We had been led to
> understand that there wouldn't be all that many distinct labels in use,
> but this seems to imply that there are going to be $bignum of them.
> That changes pg_security leakage from a can-live-with-for-first-cut
> issue to a must-fix-to-be-credible issue.

I see. SELinux handles this by dynamically filling a sidtab (context to security
identifier table) at runtime. This can be done because the contexts are stored
as strings in the xattr's. I understand KaiGai wanted to save space in the
tables so he stored sids, which would require a persistent sid mapping.

I'm not sure this is a deal breaker though, I still know people that would
rather have it now that may have performance issues than wait for something that
can prune the sid mappings.

>
> (Just for context, thousands of partitions isn't practical with our
> current implementation, but might be in the future.)
>

There are still other unresolved issues with partitions that I pointed out upthread.

>> Nonetheless, this conversation seems moot now that Tom has walled off
>> and won't even discuss row-level access controls.
>
> You realize, I trust, that I don't have the only vote around here.
> But I am convinced that the row-level-security aspect of this proposal
> is far less than fully baked, and isn't going to become so in the time
> frame available for 8.4.
>

I know, but I also know how opensource communities work :) I haven't seen any
enthusiastic support from other commiters which means, at least for the time
being, it's being tabled.

I mean no disrespect, I also agree with your assessment about the maintenance
burden. As an opensource developer myself I would be nervous about intrusive
patches that I don't understand, and what that means for me when I write new
patches.

This brings up my next point. The purpose of pgace is to mitigate this issue.
The core team only needs to know when/where/why data can be selected, updated,
deleted, etc and maintain the pgace hooks. As long as your side of the boundary
stays correct the security model shouldn't break. Granted if you add new things
(a new loadable module system, new kinds of large objects, etc) those would need
to have the hooks added from the get go.

This is similar to how the Linux kernel works, and the Xorg's XACE works. We do
watch for updates and sometimes people mess things up but it isn't hard to spot.
Especially with a small core team like postgres I'd think you guys could
successfully spot places access controls need to be added.