Re: Adding support for SE-Linux security

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Chad Sellers <csellers(at)tresys(dot)com>, "David P(dot) Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, jd(at)commandprompt(dot)com, David Fetter <david(at)fetter(dot)org>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding support for SE-Linux security
Date: 2009-12-08 18:50:53
Message-ID: 21650.1260298253@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-12-08 19:09:22 Re: tsearch parser inefficiency if text includes urls or emails - new version
Previous Message David Fetter 2009-12-08 18:28:06 Re: Sought after architectures for the PostgreSQL buildfarm?