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

Re: How to get SE-PostgreSQL acceptable

From: Joshua Brindle <method(at)manicmethod(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to get SE-PostgreSQL acceptable
Date: 2009-01-29 00:31:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Joshua Brindle <method(at)manicmethod(dot)com> writes:
>> In reality it isn't, unless postgres won't mind thousands of
>> partitions being made. In the military/gov implementations BLP lets
>> you have hierarchical levels and non-hierarchical categories. Since I
>> linked to an article about it upthread I assumed everyone
>> participating was familiar but perhaps not. Typically there are 3
>> levels, unclass, secret, top secret. In addition to those 3 levels
>> there may be a few, hundreds or even thousands of categories. Those
>> categories apply to each of the levels so if you are using 1000
>> categories you have 3*1000 possible BLP labels. On top of that SELinux
>> has users, roles and types, which are all also multiplied.
> Hmm.  If that's the expected application environment then the patch as

It's one application environment, maybe not a common one but one I've seen.

> proposed has fatal performance problems anyway, for lack of a way to
> get rid of no-longer-referenced pg_security rows.  We had been led to
> understand that there wouldn't be all that many distinct labels in use,
> but this seems to imply that there are going to be $bignum of them.
> That changes pg_security leakage from a can-live-with-for-first-cut
> issue to a must-fix-to-be-credible issue.

I see. SELinux handles this by dynamically filling a sidtab (context to security 
identifier table) at runtime. This can be done because the contexts are stored 
as strings in the xattr's. I understand KaiGai wanted to save space in the 
tables so he stored sids, which would require a persistent sid mapping.

I'm not sure this is a deal breaker though, I still know people that would 
rather have it now that may have performance issues than wait for something that 
can prune the sid mappings.

> (Just for context, thousands of partitions isn't practical with our
> current implementation, but might be in the future.)

There are still other unresolved issues with partitions that I pointed out upthread.

>> Nonetheless, this conversation seems moot now that Tom has walled off
>> and won't even discuss row-level access controls.
> You realize, I trust, that I don't have the only vote around here.
> But I am convinced that the row-level-security aspect of this proposal
> is far less than fully baked, and isn't going to become so in the time
> frame available for 8.4.

I know, but I also know how opensource communities work :) I haven't seen any 
enthusiastic support from other commiters which means, at least for the time 
being, it's being tabled.

I mean no disrespect, I also agree with your assessment about the maintenance 
burden. As an opensource developer myself I would be nervous about intrusive 
patches that I don't understand, and what that means for me when I write new 

This brings up my next point. The purpose of pgace is to mitigate this issue. 
The core team only needs to know when/where/why data can be selected, updated, 
deleted, etc and maintain the pgace hooks. As long as your side of the boundary 
stays correct the security model shouldn't break. Granted if you add new things 
(a new loadable module system, new kinds of large objects, etc) those would need 
to have the hooks added from the get go.

This is similar to how the Linux kernel works, and the Xorg's XACE works. We do 
watch for updates and sometimes people mess things up but it isn't hard to spot. 
Especially with a small core team like postgres I'd think you guys could 
successfully spot places access controls need to be added.

In response to

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-01-29 00:39:50
Subject: Re: How to get SE-PostgreSQL acceptable
Previous:From: KaiGai KoheiDate: 2009-01-29 00:03:21
Subject: Re: How to get SE-PostgreSQL acceptable

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