Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id Pine.GSO.4.64.0809161959030.19726@westnet.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
On Wed, 17 Sep 2008, Peter Eisentraut wrote:

> System-wide consistency in access controls could be nice to have in some 
> cases.  But is it really achievable?  In the typical three-tier web 
> application scenario, do you really have system-wide consistency?  Can 
> you configure your application server using SELinux?

Each of the tiers end up with mapping layer similar to the one implemented 
here to map the SELinux permissions -> PostgreSQL.  Java for example has a 
whole JVM security manager component that makes it straighforward to do 
such a mapping. 
http://articles.techrepublic.com.com/5100-10878_11-6178805.html is a good 
quick intro that shows how the call structure is similar to what the 
SE-PostgreSQL code does.

> And is SELinux really the desirable interface for a system-wide access 
> control facility?  Why not port chmod or POSIX ACLs to PostgreSQL, or port 
> SQL roles back to the operating system, or something else that captures what 
> more people are actually using in practice.

The main feature of SELinux that this crowd likes is how it manages 
privledge escalation risk.  I'm not sure if POSIX ACLs for example are as 
effective at limiting the damage an exploitable suid binary can cause. 
As for what people are actually using, as someone who lives near the US 
capital I can tell you that installs using SELinux are quite plentiful 
around here--there really is no other UNIX-based technology for this 
purpose that's gotten traction inside this government like SELinux has.

Anyway, even though I think picking SELinux as the primary security 
mechanism to integrate with is a sensible choice and I'm confident that 
the rest of the software stack isn't a problem, I do share your concern 
that implementing row and column-level security would make more sense in a 
general way first.

> Ultimately, I see this patch as an interesting proof of concept -- it got us 
> on the NSA site anyway -- but I can't see more than three people actually 
> making use of it

I take it you've never seen how big the NSA fort^H^H^H^Hfacility is?  I'm 
not sure exactly how many orders of magnitude your estimate is off by, but 
I know it's at least 2 just based on conversations I've been involved in 
with companies around here.  A lot of the US defense and homeland security 
related companies are adopting open-source software stacks because they 
can audit every level of the software, and there's a big void in that 
stack waiting for a database with the right security model to fill.  You 
are right that getting code contributions back again is a challenge 
though.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Autovacuum and Autoanalyze
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] libpq events patch (with sgml docs)