Skip site navigation (1) Skip section navigation (2)

Re: Updates of SE-PostgreSQL 8.4devel patches

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Sullivan <ajs(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-09-29 22:26:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
KaiGai Kohei wrote:
> As I repeated several times, SE-PostgreSQL applies the seuciry policy
> of SELinux to achieve consistency in access controls. This feature
> enables to restrict client's privileges on accesses to database objects,
> as if it accesses to filesystem objects. Its background is our nightmare
> for web application flaws.
> The major purpose of this feature is to provide the most important
> component to run enterprise class web application with least privilege
> set which is consistent at whole of the system.

How important is this consistency goal in reality?  We typically
recommend that database applications run entirely in the database, for
transaction integrity reasons and so on.  Unless you are doing wild and
fun things with server-side copy or untrusted procedural languages,
there really shouldn't be that much use for consistency of access
control between PostgreSQL and something else.  In fact, on top of the
transactional integrity criterion, having consistent access control is
one of the reasons to have all your production data in the database
system and nowhere else.

Of coure, this is an ideal state, and we all of to break that once in a
while.  But hence the honest question, how often does that really happen
 and to what extent, and does that justify the significant investment
that is being proposed here?

> In recent years, web application flaws are nightmare for us.
> The recent report said 95% of significant incidents on the first
> half of 2008, and 75% of them were SQL injection in Japan.
> My ultimate goal is to help the situation with mandatory access
> control and least priviled set for whole of LAPP stack.

As I had previously mentioned, we have to distinguish these two goals:
consistent access controls and mandatory access controls.

Then, how does MAC help with SQL injections?  Using the existing
role-based system you can already define least-privilege users that are
essentially powerless even if SQL injections were to happen.  I am not
aware that important flaws or gaps in our role-based access control
system have been pointed out that would make it impossible to create
applications with security levels similar to those achievable with a MAC

Now, if you come back to your original goal of consistency in access
control, then it may in fact turn out that an
FLASK/SELinux/SE-PostgreSQL-based system is the best common ground for
such a system, but I am unconvinced that MAC by itself is necessary.

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2008-09-29 23:17:23
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Previous:From: postgres Emanuel CALVO FRANCODate: 2008-09-29 21:27:51
Subject: Re: [HACKERS] PostgreSQL future ideas

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group