SE-PostgreSQL/Lite Review

It's funny; we started out this CommitFest with me scrambling to find 
someone, anyone, willing to review the latest SE-PostgreSQL patch, 
knowing it was a big job and few were likely to volunteer.  Then 
schedules lined up just right, and last night I managed to get a great 
group of people all together to do perhaps the biggest single patch 
review ever, to work on just that.    I gathered up a list of the 
biggest concerns about this feature and its associated implementation, 
we got a number of regular PostgreSQL hackers and two of the security 
guys you've seen on this list all in the same room, and we talked about 
little but SEPostgreSQL for hours.  Minutes are at 
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG and I'd 
suggest anyone interested in this feature (or in rejecting this feature) 
to take a look at what we covered.

There's comments there, with references for you [citation needed] types, 
to help answer four of the most common complaints I've seen on this list 
about this feature:

-Is there really a user base for it?
-Has it been audited by security professionals?
-Is there a useful SELinux policty to support it?
-Will this work with other security frameworks?

I feel pretty good now that these are not really our community's 
problems--these have had at least modest, and in some cases extensive, 
due diligence applied to them.  And we've confirmed there's access to 
expertise from the security community to help out with remaining 
concerns there, in person even if we plan it out right.  I personally 
suspect they've been discouraged from getting involved more by the slow 
pace this has been proceeding within our community and the general 
disarray around it, which would be understandable.

The parts I do believe we have reason to be concerned are with the code 
integration into the PostgreSQL core, and no one has any easy answers to 
things like "isn't this going to increase CERT advisories?" and "who's 
going to maintain this besides KaiGai"?  I personally feel that Steven 
Frost's recent comments here about how the PostgreSQL code makes this 
harder than it should be really cuts to the core of a next step here.  
The problem facing us isn't "is SEPostgreSQL the right solution for 
providing external security checks?"; it's "how can the PostgreSQL code 
be improved so that integrating external security is easier?"  Looking 
at SEPostgreSQL is great because it really highlights where the existing 
set of places are.  This general idea matches where thinking on things 
like row-level security was already going too--implement this for the 
database in general, then link SEPostgres in as just one provider of a 
security restriction.

I hope the review from the BWPUG helps everyone out, and that the 
suggestions on the wiki for the "Follow-up plan" are helpful.  As CF 
Manager, I feel we've given this patch its fair chunk of time this last 
month.  I don't really see any options except to mark it "returned with 
feedback" yet again for now, as this CF is nearing its close and there's 
still plenty of open issues.  My hope is that we've made progress toward 
answering some of the fundamental concerns that keep popping up around 
this patch for good, and that a plan with community members who will act 
on it (in this country for once) is coming together.  As always, we owe 
KaiGai a debt for offering his code contributions, sticking through an 
immense amount of criticism, and suggesting ways the rest of the 
database might become better overall through that interaction.  I do 
hope a committer is able to give his "Largeobject access controls" patch 
proper attention and commit it if feasible to do so.  It would be nice 
to see confirmed progress toward the larger goal of both feature and 
buzzword/checkbox complete PostgreSQL security is being made through his 
contributions.

At this point, I think someone comfortable with hacking into the 
PostgreSQL core will need to work on this project from that angle before 
even SE/PostgreSQL Lite is likely to be something we can commit.  Maybe 
we can get KaiGai thinking in those terms instead of how he's been 
approaching the problem.  Maybe Bruce or Steven can champion that work.  
I have to be honest and say that I'm not optimistic that this is 
possible or even a good idea to accomplish in the time remaining during 
this release.  A patch that touches the security model in fairly 
fundamental ways seems like it would be much better as an alpha-1 
candidate, while there's still plenty of time to shake out issues, than 
as a beta-1 or even alpha-3 one.  And I'm skeptical that this feature 
really fits the true use-cases for SEPostgres without row-level 
filtering anyway.  After our talk last night, it's obvious we need to 
figure out how to get that back before including the code does what 
people really want here.  But based on looking at the market for this 
sort of feature, providing this new form of security integrated into the 
database does seem like a worthwhile goal.  I wouldn't have spent this 
much time talking about it if I didn't believe that to be true.  On my 
side, in addition to helping coordinate everyone pushing in the same 
direction, I'll also continue trying to shake out some sponsorship 
funding for additional work out of the people in this country it would 
benefit.  It seems I'm going to keep getting pulled into the middle of 
this area regularly anyway.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com