Re: Updates of SE-PostgreSQL 8.4devel patches

KaiGai Kohei wrote:
> Robert Haas wrote:
> >> Can you *do* the row-level permission?
> >
> > I don't think there's any consensus on a design.
>
> Yes, unfortunatelly.
> No one replied to my proposed design:
> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2

Yes, we got stuck on the covert channels issue. Frankly I think the use
of non-natural keys addresses most of the covert channel issues and
should be recommended for secure setups --- I don't think we are going to
do any better than that and think we need to move forward on that
assumption. We can cite
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950, which
outlines the security risks.

> > Getting consensus on a design seems to actually be one of the harder
> > aspects of PostgreSQL development. The pattern seems to be:
> >
> > 1. Someone submits a patch. By definition, the patch embodies some
> > particular design.
> > 2. One or more members of core express concerns about the design
> > embodied in the patch.
> > 3. If the concerns are fairly specific and not mutually contradictory,
> > the submitter revises the patch accordingly and it gets committed
> > (hopefully without having to discard too much of their previous work).
> > 4. If the concerns are fairly vague and open-ended, or if they
> > contract each other, the patch hovers in limbo for eternity.
> >
> > I'm not sure what the solution to this problem is. The fact that a
> > member of core does not like a particular design for feature X does
> > not oblige that person to produce a better one, but it's pretty tough
> > to proceed without it.

Yes, see above --- I think it is time to move forward.

> Yes, I have had similar experiences in Linux kernel development for
> several years.
> The amount of time to get consensus is one of the reason why I want
> to move the SQL based row-level security to v8.5 development cycle.

As I stated before, I think doing an SE-Linux version and then adding a
more generalized solution is doing things in the wrong order because
the generalized solution is going to have to re-do the SE-Linux stuff.
As much as I would like to see SE-Linux support in 8.4, I think we need
general column and row-level permission built with an eye on what
SE-Linux will need, then add SE-Linux security.

> > In the case of SE-PostgreSQL, two members of core expressed concerns:
> >
> > - Peter Eisentraut expressed concern about implementing row-level
> > security via SE-PostgreSQL without first implementing some sort of
> > SQL-based row-level security. KaiGai expressed willingness to
> > implement that, but we still don't have a design, so I assume KaiGai
> > is going to implement... something... and hope that it turns out to be
> > acceptable.
>
> Its conclusion is actually not clear for me.
> The proposed SQL based row-level security assumes what he pointed out
> is right, but I don't know the reason why it should be placed prior.
>
> I guess he intend to share the code for row-level security, thus it
> should be implemented prior to the OS specific feature. But most of
> SE-PostgreSQL code is separated from core implementation and invoked
> via security hooks, so it is unsuitable to share code with other
> facilities.

You are right based on line counts in the patch, but based on actual
changes to the existing code, SE-Linux changes very much match what
SQL-level permissions would need.

> > - Tom Lane expressed concerns about covert channels to which KaiGai
> > responded, AIUI, that the patch was pretty useful even without
> > addressing that issue, but if Tom isn't willing to see the patch
> > committed otherwise, then KaiGai has to decide between giving up and
> > attempting to implement some form of polyinstantiation - which will
> > not be easy, and which is far from guaranteed to be accepted if he
> > does develop it.
>
> Its conclusion it not clear.
>
> I think the polyinstantiation is too much requirements, as prior major

Agreed on polyinstantiation.

> commercial RDBMS with row-level security (like Oracle Label Security)
> does not care about such kind of covert channels.
> It is quite natural to describe such kind of limitation/specification
> on the documentation explicitly to help end-user's decision.

Agreed.

> > In both cases, the lack of a clear roadmap means that a dedicated
> > developer is potentially putting in a lot of time and effort
> > developing what may end up being a complete dead-end.
>
> I believe such a situation will help nobody get happy.

I think we need to see a specification on how SQL-level row permissions
would work, and get column-level permissions into CVS.

To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
has little disruption, but 30% are changes to the core backend code,
which will be disruptive, so we would like to have SQL-level permissions
that everyone uses to be that disruption, and have SE-Linux attach to
those capabilities.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +