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 just wanted to add some talking notes here.
User base for the feature:
While my goals for this feature line up with military/government users
this is in no way the extent of the potential user base. The fact is
most people won't know they want this feature until it is available. Why
is that? Well, how many of you have written webapps and implemented
policy logic in your application rather than the database level? Why do
people currently feel the need to do this? Is it even possible to
implement some complex policies (eg., PCI compliance) at the database
level? If PostgreSQL version whatever suddenly had the ability to
implement the policy logic in the database, would you move it there? I
know I would..
Audit:
In past conversations it sounded like some of the Postgres community was
skeptical even about the design of the security model. For an even
earlier look (September 2006) of KaiGai and the SELinux community
talking about the object model and even high level design of the
solution see <http://marc.info/?l=selinux&m=115762285013528&w=2>
I've read through some of the prior patches, but haven't done an
extensive audit, not only because of the size but because it became
apparent relatively quickly that it was a waste of time and the
community here wasn't going to accept it anyway. If this situation
changes I think you'll find a few of us willing to donate time to the cause.
Policy:
The policy is easy once you have an object model that covers your use
cases. You can see in the above discussion how we came to the object
model we have now and why I've been comfortable with it since then.
An interesting aside, we must have hit the object model pretty well
since another RDBMS (Trusted Rubix) uses the same one as SEPostgreSQL.
See <http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf>
Works outside of SELinux:
As Stephen already pointed out, Casey Schaufler (CC'd) who is the author
of SMACK <http://schaufler-ca.com/> believes that the abstractions
provided by PGACE will allow integration of his security system as well.
SMACK is already in the Linux kernel as an alternative LSM to SELinux.
Further, not that I've seen the code or know how they did it, Trusted
Rubix has support for multiple access control systems
<http://rubix.com/cms/features> including Trusted Solaris, Solaris
Trusted Extensions, SELinux and their own RBAC system.
--
With all that said, I've very interested in seeing this work move along.
In its current shape it has limited utility in my world (although I know
of at least 2 solutions I've seen that run 20 Postgres servers on a
single system just to have database separation). The main thing that
prevents it from being used in that situation today is superuser access
(eg., we can't have superusers that can go around and muck in data he's
not cleared for). But I recognize that this is a first step to a
potentially great system and I definitely want to see it moving forward.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
