Re: SE-PostgreSQL/Lite Review - Mailing list pgsql-hackers

On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote:
> Greg Smith wrote:
> > 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.
>
> I repent that I cannot attend here.
> The wikipage is a good summarize. Thanks for your efforts.
>
> > 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.
>
> IMO, the slow pace is not a primary reason. In fact, SELinux was released
> at 2000 Dec, but it gets integtated into the mainline kernel at 2003 Aug
> with various kind of improvements. It takes about 3 years from the first
> relase. IIRC, now we take 2.5 years from the first announce of SE-PgSQL
> in this list, and various kind of improvements and cleanups had been done.
> It is a bit long term, but not too long term.
>
> The reason of this gap is that people have individual consciousness about
> their security. I often represent it as "security is a subjective term".
> Needless to say, we don't have magic-bullets for any threats. Any
> technology has its metirs and limitations. However, people tend to say "it
> is nonsense", if the feature does not match with their recognizable demands
> or threats.
>
> Security-folks know MAC is not magic-bullets, while it is a significant
> piece of system security. But some of complaints might be pointless for
> security experts, so had been dismotivated.
> From the perspective of security folks, we have to introduce it doggedly.
> And, I'd like to understand database folks there are various kind of
> security models and viewpoints here. SELinux is one of them.
>
> > 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.
>
> Right, it seems to me the "security provider" is a good phrase to represent
> this feature. It just provides additional access control decisions based on
> the different perspective of security model.
>
> Please note that the access control granularity is not an essential issue.
> We can also assume table-level mandatory access controls for instance.
>
> The latest patch provides table/column level controls without row-level,
> because the current PgSQL has facilities to know what tables and columns
> are referenced reasonably, so SE-PgSQL also can know what tables/columns
> are referenced without special tricks.
>
> Please remind the earlier SE-PgSQL in v8.2.x. It walked on the Query tree
> to pick up what columns were accessed.
>
> > 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.
>
> I don't believe all works will be closed within 5 days.
> Thanks for your and BWPUG's offer. I'll provide my maximum efforts to
> become it commitable in the last commit fest.
>
> > 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.
>
> It is not a one-sided contribution.
> When we implement SE-PgSQL with full functionality, access controls on
> large objects are absolutely necessary. I consider it is a groundwork.
>
> > 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.
>
> One point. I'd like to introduce a use case without row-level granularity.
>
> The page.24 in this slide:
>   http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf
>
> shows SELinux performs as a logical wall between virtual domains in
> web-services. Unlike physical database separation, it also allows to
> share a part of files/tables from multiple virtual hosts, because of
> its flexibility.
>

I got the impression that this is doable with current SEPostgres stuff, would 
be nice to see a little more detailed writeup on how to do it. Especially if 
it could be linked to the hosting providors page in the wiki. 

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com