SELinux and PostgreSQL: a worthwhile union?

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

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

PostgreSQL hacker Bruce Momjian was pleased with the reduced patch, saying that is "exactly what I was hoping to see." He also noted, though:

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

That leaves the cost/benefit question. The strongest critic of this patch is almost certainly Tom Lane, who said:

On the other hand, Josh Berkus noted that he has seen interest in the feature:

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.