SE-Postgres tightens SQL security

This post was contributed by Joshua Kramer. For more information about Kramer, go to the EnterpriseLinuxLog About the Editors page.

In the theater of IT operations, security has moved to center stage. Attacks have become more complex, and legislative bodies have passed laws that require data protection. In just the past year, Nevada and Massachusetts introduced legislation requiring that consumer data be protected. 

 In 2006, Oracle introduced its Audit Vault, which purported to restrict access to data even from database management administrators. This kind of tool is extremely valuable in the fight against those trying to steal personal information.  

In early 2009, another player will offer a similar — and perhaps more secure — way to restrict data access As part of its yearly feature update, the PostgreSQL group plans to implement a module called SE-Postgres in the database core. This module inherits security rules and contexts from the SELinux rule set of the host OS to control access to tables, individual rows of data and even individual columns. Currently SE-Postgres is available as a patch to the Postgres 8.3 database (for those who don’t mind compiling source code). 

This inheritance of rules applies to all facets of SELinux and therefore gives you power beyond simply restricting access by role. When SE-Postgres is configured properly, a client’s SELinux context is propagated to all data it touches. For example, rows inserted by a subject with SystemHigh privileges will carry the Secret label. A query submitted by a subject with user_t privileges will not return rows that have such a label. For the most part, referential integrity is preserved; a table join will fail if one of the objects required in a table is disallowed by SELinux context. There are a few minor exceptions, but those will be closed as the project progresses.