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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
