When your editor was in Tokyo recently, he had the privilege to talk with
KaiGai Kohei at some length about the SE-PgSQL patch set. This work,
developed by KaiGai for the last two years or so, integrates SELinux with
the PostgreSQL database manager, enabling fine-grained control over access
to data stored within a database. The SE-PgSQL patch has struggled to get
into the PostgreSQL mainline; it is now preparing for what may well be its
last push to be merged. Whether it's successful may, in the end, depend on
whether it receives support from potential users.
SELinux works by attaching labels to objects and roles to actors, then
enforcing rules describing what sort of access to objects with specific
labels is allowed to specific roles. It is a highly flexible system, but
also highly complex; even a minimal SELinux policy can involve thousands of
rules. The complexity of SELinux has almost certainly inhibited its
adoption in the broader Linux community; when SELinux gets in the way
of real work, figuring out how to fix it can be a nontrivial task. Over
the years, many administrators have concluded, like Ted Ts'o, that "life is too
short for SELinux."
That said, Fedora and Red Hat have slowly made progress in using SELinux to
confine parts of the system without creating too much user pain. And there
is certainly a place for more comprehensive security models in general. But once one
starts protecting data at the filesystem level, it makes sense to ask
whether data which is accessed through higher-level mechanisms - a
relational database manager, say - should also be subject to the system's
security policies. In an ideal world, the same security policy would be
operative at all levels.
That is the idea behind SE-PgSQL. With this patch, a database
administrator can assign labels to databases, schemas, rows, and columns,
then write access control rules for them. These are SELinux rules, which
are evaluated by SELinux and enforced by PostgreSQL. So access to objects
within the database can be governed by the same policy as access to objects
elsewhere in the system. On the surface, it is an elegant concept. It is
also a concept that NEC (KaiGai's employer) sees as an important component
of its future offerings based around cloud computing. For this reason, NEC
has funded this work for the last couple of years.
The world is full of free software projects which are starved for
developers and which would be overjoyed to accept a feature contribution at
this level. The PostgreSQL hackers are somewhat more finicky, though. As
is the case with a number of longstanding, successful projects, PostgreSQL
developers understand that they will be maintaining any code they accept
for many years, and that they cannot afford to accept code which might
compromise the project's reputation for stability. So they have been
balking at merging SE-PgSQL.
There would appear to be two specific objections getting in the way of
this patch: (1) it's big, complicated, and hard to understand, and
(2) it's not
clear that the benefit of merging this functionality will be worth the
To address the first qualm, KaiGai has worked to minimize the patch to the
greatest extent possible, stripping out much of the functionality in the
process. Among other things, the latest version of the code does not
support row-level labeling. He has also written some extensive
documentation which should be required reading for anybody wanting to
understand how this patch should work. The end result is a patch which
still weighs in at 13,000 lines - but the bulk of it is documentation and
PostgreSQL hacker Bruce Momjian was pleased with
the reduced patch, saying that is "exactly what I was hoping to
see." He also noted, though:
So, one big problem is that no one has agreed to review it, partly
or probably because few developers understand the SE-Linux API, and
many people who have used SE-Linux have been confused by it.
He expressed willingness to do the review, but requested help from
developers who understand SELinux better. KaiGai has offered to try to
round up such a developer, so, with luck, this particular obstacle can be
That leaves the cost/benefit question. The strongest critic of this patch
is almost certainly Tom Lane, who said:
Even if we were to accept the SEPostgres patches lock stock and
barrel tomorrow, I don't foresee that it will ever get to the point
of being useful except to an extremely small group of users who are
driven by extreme need. Nobody else is going to have the
motivation needed to develop custom security policies, and there
simply isn't any chance of anyone developing any generally useful
On the other hand, Josh Berkus noted that
he has seen interest in the feature:
PostgreSQL is the most security-conscious of the OSS databases, and
is widely used by certain groups (security software, military,
credit card processing) precisely because of this reputation.
These folks, while unlikely to speak up on -hackers, are interested
in new/further security features; when I was at the Pentagon 2
years ago several people there from HS were quite interested in
SE-Postgres specifically. Further, I've been mentioning
SE-Postgres in my "DB security talk" for the last 18 months and I
*always* get a question about it.
This unwillingness to speak up on the part of potential users could well
doom this patch. The code probably cannot be minimized much further
without becoming pointless, and even a contributor as persistent and
patient as KaiGai can only get discouraged eventually. It would not be
surprising if this PostgreSQL development cycle were the last go-round for
SE-PgSQL if it is not accepted.
Part of participating in a free software community is contributing code.
But another important part is providing feedback to the developers.
Otherwise, they are unlikely to know which development directions
make sense for many of their users, and they might just turn down patches
which their users would rather see incorporated. Companies are often
reluctant to talk about their security needs and plans. But, for potential
SE-PgSQL users, that kind of silence at this time could be
counterproductive. If nobody shows up to express a need for SELinux
integration into PostgreSQL, the developers might conclude that there is no
interest in this feature and act accordingly.
to post comments)