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(at)2ndQuadrant(dot)com www.2ndQuadrant.com