Re: SE-PostgreSQL/Lite Review

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.

The MCS (multi catagory security) policy is suitable for such a system,
and it has been provided for more than four years, easy configurable.
It will well match with ISP use case in the wiki.

I'm also an author of mod_selinux module. I don't have actual number of
users, but I often asked questions to set up it.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>