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-10-09 14:21:55
Message-ID: 20081009142155.GC46922@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, Sep 27, 2008 at 12:18:45PM +0900, KaiGai Kohei wrote:
>
> As I repeated several times, SE-PostgreSQL applies the seuciry policy
> of SELinux to achieve consistency in access controls.

I get this. The problem as I see it is that the SELinux security
policy is designed around a very different set of assumptions about
concurrency and consistency than any database system has to provide.
My admittedly hurried glance at some abstracts in the literature
suggests to me that others have looked at the paradoxes that come out
of this kind of security policy consistency when you apply them to
database systems. I think that clearly stating which of the
trade-offs are the ones to be accepted is all that's needed.

> In my vision, Apache assigns its contents handler an individual
> security context based on HTTP authentication, source IP address
> and so on just before web application invoked.
> Because web applications works with individual least privilege set,
> its accesses on filesystem are restricted by the security policy.
> In a similar way, its accesses on databases are also restricted
> via SE-PostgreSQL by same policy, by same privilege set.

I want to focus on this description, because you appear to be limiting
the problem scope tremendously here. We've moved from "general
security policy for database system" to "security policy for database
system as part of a web-application stack". I suggest that the range
of practically available behaviours of the DBMS working as part of a
web-application stack is a subset of the practically available
behaviours of the DBMS overall. This could be the source of some of
the difficulty. For instance, it seems that some scenarios people are
worried about are really the sort of scenario relevant to online users
of Postgres, rather than to people seeing results filtered through a
web application. If we just don't care about the online, interactive
users, then maybe some of those concerns go away. (I'll be honest,
though, that I have a hard time getting excited about a security
system that doesn't really work as advertised outside of a narrow
context.)

All that said, I think there are definite practical uses for the work
you're undertaking, and I want to emphasise that I think the general
goal is probably a good one. I am suggesting that some additional
work clarifying the specific goals of the work is all that's really
needed.

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 Tom Lane 2008-10-09 14:36:02 Re: CREATE DATABASE vs delayed table unlink
Previous Message Andrew Sullivan 2008-10-09 14:01:34 Re: Updates of SE-PostgreSQL 8.4devel patches