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

From KaiGai Kohei
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 48D0A375.6020400@ak.jp.nec.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith wrote:
> 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.

I guess these security architectures have same origin.

The reference monitor concept requres all accesses to data objects to be
checked by a tamperproof, always-invoked module based on its policy.  http://en.wikipedia.org/wiki/Reference_monitor

SE-PostgreSQL uses in-kernel SELinux as a reference monitor to check
all accesses to database object via SQL.

>> 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.

Thanks for your explanation.

The PGACE security framework can mount a OS independent fine
grained access control feature, like Oracle Label Security.
However, one concern is we have only one CommitFest remained.

As I mentioned at the previous message, I think it is not
a strange behavior that different security subsystems make
different decisions on individual gulanualities.


>> 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.

I don't have statistically reliable information. :)
However, I believe there is potentially strong demand for secure database
due to responses from audiences when I had presentations about SE-PostgreSQL
in various opportunities.

IIRC, Josh also said similar things.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Autovacuum and Autoanalyze
Next
From: Heikki Linnakangas
Date:
Subject: Re: Autovacuum and Autoanalyze