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 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.