Re: Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> One of the major and fundamental stumbling blocks we've run into is
>> that every solution we've looked at so far seems to involve adding
>> SE-Linux-specific checks in many places in the code.  It would be nice
>> if it were possible to use the exist permissions-checking functions
>> and have them check a few more things while they're at it, but it's
>> looking like that won't be feasible, or at least no one's come up with
>> a plausible design yet.
>
> I don't think that it's about SELinux.  The real issue here is that
> KaiGai-san is about a mile out in front of the PG hackers community
> in terms of his ambitions for the scope of what can be controlled by
> security policy.  If the patch were only doing what the community has
> actually agreed to, there would be little need for it to touch anything
> but the aclcheck functions.
>
> Now I recognize that a large part of the potential attraction in this
> for the security community is exactly the idea of having fine-grain
> security control.  But if you ever want anything significantly different
> from SQL-standard permission mechanisms, there's going to have to be a
> whole lot more work done.  Basically, nobody in the PG community has got
> any confidence either in the overall design or the implementation
> details for locking things down that aren't already controlled by SQL
> permission mechanisms.

I think that's basically right. Further, I think this is basically a
resource issue. If you were inclined to spend a large amount of your
time on this problem, you could either gain confidence in the present
design and implementation or come up with a new one in which you did
have confidence. But it doesn't seem important enough to you (or your
employer) for the amount of time it would take, so you're not. I
think there are other committers and community members in a similar
situation - basically all of them.

...Robert