Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

KaiGai Kohei wrote:
> Could you tell me the current status of reviewing process in the 
> CommitFest:Sep?

Well ... I have analyzed this patch several times now.  The 
implementation appears to be pretty straightforward, and when the time 
comes, we can discuss some of the low-level details.

At this time, however, I would like to take a step or two back and 
discuss with the rest of the community what we really want to achieve in 
terms of enhancing "security" and access control.  We need wider input 
on this.  The patch makes use of generic terms such as "security 
enhanced" and "access control extensions" and appropriates them to this 
particular implementation, and I am not really sure what direction we 
want to take with this.  I have also reviewed your PGCon presentation to 
infer your goals behind this implementation.

At the core of it, I can see a few things that are being done here:

* System-wide consistency in access controls

The idea is, if we use some system and language to control operating 
system permissions, it would be nice to use the same system and language 
to control access permissions in the database system and elsewhere.

* Mandatory access control (MAC)

This defines a global security policy on top of the discretionary access 
control currently in place.  (Depending on how you interpret the terms 
and the capabilities of SELinux, it also provides Type Enforcement and 
Multilevel Security to some degree.  These are related in some ways to MAC.)

* Row-level security

This defines a way to control access to rows, not only to columns.

* Additional privileges

The presented patches add ways to control permissions to alter tables, 
modify large objects, and other things as well as column-level 
privileges.  Some of this is a moral prerequisite for a useful MAC setup.


Now these items are arguably useful and welcome features in their own 
right.  Unfortunately, this patch has chosen to provide these features 
in a way that makes them accessible to the least amount of users.  And 
moreover, it bunches them all in one feature, while they should really 
be available independently.

Let's review:

*) System-wide consistency in access controls could be nice to have in 
some cases.  But is it really achievable?  In the typical three-tier web 
application scenario, do you really have system-wide consistency?  Can 
you configure your application server using SELinux?  I'm no expert on 
these things, but I wonder, would it even work in a useful way, over the 
network, with all the different threads, processes, and sessions going 
on?  Or how about a desktop, pgAdmin with several database connections, 
can those be isolated from each other or whatever the security setup may be?

And is SELinux really the desirable interface for a system-wide access 
control facility?  Why not port chmod or POSIX ACLs to PostgreSQL, or 
port SQL roles back to the operating system, or something else that 
captures what more people are actually using in practice.

*) Mandatory access control could be a useful feature for some users. 
But must we resort to SELinux as the configuration language and 
implementation backend?  Why couldn't we implement a MAC system in SQL 
using the existing language?

Also, what I read is that role-based access control (RBAC) systems are 
equally capable of providing the sort of stronger security that MAC 
users are typically looking for.  (In some ways, it appears to be the 
newer thing.)  PostgreSQL already has a pretty good role system, so we 
could perhaps look into enhancing that to meet the necessary functional 
criteria that may exist.

*) Row-level security, column-level security and so on should in my mind 
first exist as a native SQL-level feature.  It would be hard to explain 
that PostgreSQL does not have column-level GRANT privileges but that you 
can achieve the same if you go through SELinux.  After all, the 
SE-PostgreSQL patch only hooks in to several places to throw "permission 
denied errors" when appropriate, so native SQL features should be able 
to achieve the same.  (Well, there are interesting SELinux-vs-AppArmor 
type differences here, that may be worth considering separately.)


Ultimately, I see this patch as an interesting proof of concept -- it 
got us on the NSA site anyway -- but I can't see more than three people 
actually making use of it, and they are not going to maintain this code 
for us in the long run.  On the other hand, it provides useful features, 
but with what I consider suboptimal interfaces.  Considering that 
SELinux configurations on Red Hat are now just slowly evolving from 
annoying to usable after many years of work, I can't see us mustering 
the resources to achieve a usable configuration of this in a reasonable 
time, let alone the resources required to verify the whole thing so that 
is actually provides some assurances rather than just another way to 
fiddle about with the system.

The way I see this, the approach to be taken to achieve some kind of 
government-grade security system would be:

1. Implement row-level security, column-level privileges, and all other 
necessary permission bits as SQL features.

2. Enhance the role system to meet whatever the evaluation criteria may be.

3a. Add access control extension hooks.

3b. Implement SELinux on top of these hooks.

You have already done 3a and 3b, but I think 1 and 2 should be done first.