Re: Updates of SE-PostgreSQL 8.4devel patches

From: Andrew Sullivan <ajs(at)commandprompt(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-09-26 13:34:41
Message-ID: 20080926133440.GB1005@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 25, 2008 at 08:57:46PM -0400, Tom Lane wrote:
> Another point is that the proposed behavior leaks quite a lot of
> information, since it will fail operations on the basis of tuples that
> supposedly aren't visible to the invoking user. While I admit that it's
> hard to see an alternative if we're to preserve FK integrity, I have to
> worry that this definition isn't going to satisfy the tin-foil-hat
> brigade that are supposed to be the main users of SEPostgres. If the
> goal is "you don't know the row is there", this doesn't seem to meet it.

The above point, and other similar ones in every discussion of the
proposed functionality, makes me think once again either that the
requirements for this feature aren't understood by everyone, or else
that they're not actually explicit enough. I have a feeling it's the
latter. Certainly, I've not yet read a complete security analysis of
a data system security plan that outlines why the proposed model is
correct.

What I think is really happening with this development is that the
SE-Linux understanding of "security enhancement" has been taken as the
correct analysis for how one secures an information system. That deep
assumption appears to me to be informing much of the development of
SE-PostgreSQL. In particular, that deep assumption includes an
assumption that consistency of access control trumps all. The
Postgres developers who are questioning the SE approach are (I think)
coming at this from the point of view of data systems developers,
where consistency of the data set trumps all.

I suspect that the tension between these approaches will not be
reconciled without a fairly complete outline of possible security
models for data systems, their relationship to what the OS security
people have decided is the right thing to do, and the trade-offs
necessary to make different priorities work. Some of the trade offs
may include things like "violate traditional understanding of data set
consistency" and "possible disclosure of existence of datum". I think
this will be a lot of work, and I'm not volunteering to do it. I
nevertheless think that without it, the SE-PostgreSQL features will
continue to be a very awkward fit.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2008-09-26 13:39:04 Re: Updates of SE-PostgreSQL 8.4devel patches
Previous Message Andrew Dunstan 2008-09-26 13:25:04 Re: parallel pg_restore - WIP patch