SELinux and PostgreSQL: a worthwhile union?
Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
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 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.
(Log in to post comments)
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 4, 2009 20:26 UTC (Fri) by mjthayer (guest, #39183) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 4, 2009 22:32 UTC (Fri) by dpquigl (guest, #52852) [Link]
In addition to SE-Postgres work has been done in the X server to provide a framework similar to the LSM framework called XACE (X Access Control Extensions). Just like the LSM framework you can create modules for XACE and one for SELinux has been developed. So the X server is acting as the enforcement mechanism and it queries the kernel security server to ask about access decisions just like SE-Postgres does.
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 7, 2009 2:35 UTC (Mon) by kaigai (guest, #12001) [Link]
It manages system resources such as files and networks.
When a user tries to access these resources, he has to invoke system calls.
The kernel has routines to handle system calls, and these routines
voluntarily
invoke SELinux code (via LSM) whether the requires access should be allowed,
or not.
SELinux makes its access control decision, and return it into the caller,
then the caller performs according to the decision.
On the model, we call it "security server" which can provide access control
decision independent from the class of subsystems.
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 10, 2009 10:29 UTC (Thu) by mjthayer (guest, #39183) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 4, 2009 21:41 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 4, 2009 22:44 UTC (Fri) by dlang (guest, #313) [Link]
the reason is that Oracle offers a similar capability, and checkbox management frequently sees such things as significant, even if they don't end up using them (after all, they may need to do more in the future and use it, so if postgres doesn't do this and oracle does they should stick with oracle)
personally, i don't believe that trying to do this level of permissions inside the database is appropriate. I believe that if you are this worried about your data you should not give the applications direct access to the database, they should talk to a shim layer that is small and can be tested to only generate expected queries to the database.
Why?
Posted Dec 5, 2009 1:33 UTC (Sat) by gbutler69 (guest, #54063) [Link]
and row permissions/restrictions are good/better?
Why?
Posted Dec 5, 2009 4:07 UTC (Sat) by cetialphav (subscriber, #22533) [Link]
I can see where there could be some interesting usage for the integration of databases and SELinux. Many organizations have a centralized database storing everything, yet few departments actually should be able to see the whole thing. I am thinking of something like a medical institution where the people doing the billing need to know what I owe, but don't need my medical history. Of course, databases already offer ways to limit what certain users see, but security people don't have a centralized way to set these policies.
This kind of integration is one step towards giving administrators one centralized place to set the security policy and I think that offers a lot of benefits. The difficulty of writing these policies in SELinux is an issue, but I can see where companies like IBM would be happy to offer this as a consulting service.
Why?
Posted Dec 10, 2009 14:00 UTC (Thu) by Baylink (guest, #755) [Link]
Correct.
But that's not a bug, it's a feature!<tm>
A shim can be expected, generally, to be *much* smaller than the code on either side of it -- by 2 or 3 orders of magnitude if not more, unless someone's done something horribly wrong -- and should therefore be *much* easier to prove correct.
Why?
Posted Dec 5, 2009 4:26 UTC (Sat) by SEJeff (guest, #51588) [Link]
Why?
Posted Dec 6, 2009 2:00 UTC (Sun) by flewellyn (subscriber, #5047) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 6, 2009 1:42 UTC (Sun) by dfetter (guest, #40012) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 6, 2009 7:00 UTC (Sun) by yodermk (guest, #3803) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 6, 2009 17:32 UTC (Sun) by Los__D (guest, #15263) [Link]
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 7, 2009 2:22 UTC (Mon) by kaigai (guest, #12001) [Link]
> could prevent but the excellent Postgres permission structure could not?
Can the page.24 of this slides help you?
http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_S...
It allows SELinux to perform a logical-wall to separate each virtual-hosts
in a single tenant. However, it also has flexibility to share partial
tables or files across virtual domains, unlike virtualization.
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 10, 2009 9:10 UTC (Thu) by smurf (subscriber, #17840) [Link]
Any kind of multi-customer database can benefit from that. Last year I had to tell a customer that converting his single-client database solution to multi-client wasn't possible without major redesign. With row-level access control I'd have been able to make them happy (and me too, by billing them for a month or so of work ;-) ).
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 6, 2009 12:35 UTC (Sun) by marcH (subscriber, #57642) [Link]
> the broader Linux community;
Is any SELinux policy really complex or just verbose? If it is really
complex then it cannot be secure. Anything complex has (at least) minor
bugs. In security, a minor bug is a security hole.
I hope any SELinux policy is just verbose because it needs to micro-manage
every object and action in the system. I hope it is not actually complex,
every object or action actually depending on a _small_ number of SELinux
configuration items.
Sorry for being such a SELinux newbie - however I suspect I am far from
being the only one. Could any SELinux knowledgeable person confirm or
infirm the above?
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 7, 2009 2:54 UTC (Mon) by kaigai (guest, #12001) [Link]
in much early phase.
So, in past, it made various kind of troubles, so SELinux developers have
continued to improve it for a long time.
Nowadays, we can see few cases which need to write our custom security
policy,
because the default security policy provides various kind of predefined
security policies. We can choose them as necessary, without writing our
custom security policy module.
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 7, 2009 16:03 UTC (Mon) by dpquigl (guest, #52852) [Link]
The reality of the situation is this. SELinux is a default deny system where the policy consists of rules that say what is allowed. When you do this you have to basically model in policy the entire system and all applications running on it. To make it easier for people to write policy the reference policy has been broken up into several layers and exposes interfaces for policy writers to use instead of writing raw allow rules. However this yields a large policy because the system we're trying to protect is large and complex. We have examples of much smaller policies being written and applied but these are on more special purpose deployments where the set of deployed applications is much smaller.
Now KaiGai is right in that a distro's integration of SELinux is very important. Since you're describing in policy the default behavior of the system it is important that all of the distro specific nuances are addressed. You can see this in the reference policy in places where there are distro checks for debian vs fedora. This is where most of the issues that people have with SELinux stem from. Dan Walsh has an article on his blog titled "4 things SELinux is trying to tell you" (or something like that)[1] that explains SELinux problems.
That said Fedora/RHEL and Debian/Ubuntu[2] have well supported SELinux integration with SUSE to make progress[3][4]. Its worth noting that I couldn't find a blog posting from Tom on SELinux support in opensuse 11.3 so its possible it has gotten better since his description of what he wants in 11.2. If you use the system as it is deployed out of the box then the SELinux policy should match up with the running system. If there are denials then that is a policy bug and should be reported to the guys at Tresys or through your distro specific bug tracking site. The problems are when people start moving things to non-standard places and then don't realize that just like the ugo bits they may have to set the SELinux label on the file as well. Dan's presentation and paper give a really good explination of this so I'd recommend reating that rather than having me repeat it here.
[1] http://danwalsh.livejournal.com/30837.html
[2] https://wiki.ubuntu.com/SELinux
[3] http://thetoms-random-thoughts.blogspot.com/2008/12/selin...
[4] http://thetoms-random-thoughts.blogspot.com/2009/06/selin...
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 13, 2009 19:21 UTC (Sun) by marcH (subscriber, #57642) [Link]
Shouldn't SELinux policies be split across packages? (I mean RPMs/debs.) After all there is no centralized database to manage the good old file system permissions. And rightly so.
SELinux and PostgreSQL: a worthwhile union?
Posted Dec 11, 2009 0:32 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
So most 'casual users' and administrators just turn SELinux off. Besides, with SELinux you also need to 'label' your filesystem. And if you're using an NFS, SMB or FAT32 partition - tough luck, then.
That's why I'm advocating for AppArmor - it's quite easy to use. You can write a policy for a simple daemon in 10 minutes, literally. And it'll be intuitively understandable. And it won't require you to label you filesystem.
And it'll be just as secure for most applications as is SELinux.
replace the actual security framework with SE-PgSQL to reduce complexity
Posted Dec 10, 2009 7:05 UTC (Thu) by zmi (guest, #4829) [Link]
The problem I see is that it would require SELinux to run on the system. Maybe there can be a postgresql selinux daemon to support that if the system as a whole doesn't run SELinux.
Having only one framework is better than two in terms of security. If once in the years to come SELinux will be usable in default installs, PostgreSQL could have a stable implementation already.