Re: 8.4 release planning - Mailing list pgsql-hackers

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> Tom Lane wrote:
>>> The second problem is that we're not sure it's really the right thing,
>>> because we have no one who is competent to review the design from a
>>> security standpoint.
> 
>> Are we underestimating Kaigai Kohei?
> 
> Perhaps he walks on water, but still I'd like to have more than one
> person who has confidence that this design and implementation are correct.
> 
>> and it seems his patches there related to postgresql were pretty widely
>> discussed on the SELinux lists:
>>   http://www.nsa.gov/research/selinux/list-archive/0805/index.shtml#26163
> 
> Well, a quick look through that thread shows a lot of discussion of the
> selinux policy code that's in the patch, which is good as far as it goes
> because for sure there's no one in *this* list who understands a line of
> that stuff.  But to be blunt there's no evidence there that anyone in
> that discussion has heard of a foreign key, much less understands why
> it might be an issue for this patch.  I see a lot of reasoning by
> analogy to X servers, and little if any database-specific knowledge.
> 

http://marc.info/?l=selinux&m=115762285013528&w=2

Is the original discussion thread for the security model used in the 
sepostgresql work. Hopefully you'll see some of the evidence you speak of there.

For some additional resources there is a good chapter on database security 
(specifically multilevel databases) in Pfleeger's Security in Computing:
http://www.amazon.com/Security-Computing-Second-Charles-Pfleeger/dp/0133374866/ref=si3_rdr_bb_product


> Mind you, I'd like nothing better than to have some NSA database
> security experts (I'm sure there are some) show up here and tell us that
> this design is good, secure, and useful --- and why.  But right now we
> have no evidence for that proposition.  And we really need to understand
> *why* it's a useful design and what the critical security issues are,
> because otherwise we are 100% certain to break it in future maintenance
> (even granting the improbable supposition that there are no bugs in the
> patch today).
> 

This capability puts PostgreSQL in a unique position. Not only is the security 
model more fine grained than any previous trusted database but it also allows 
interesting things like trusted stored procedures that can access data (and do 
any necessary fuzzing, modifying or filtering) that the client himself cannot read.

It also integrates well with the labeled networking supplied by SELinux, as 
outlined on KaiGai's wiki page. There can be multiple clients running on one 
machine (such as a web server) that have different levels of database access, in 
a more fine grained and flexible way than using different database credentials 
allows.

I'm happy to discuss this at length if it will help the patches get upstreamed.