Back in September, I wrote two blog posts on SE-Linux integration for PostgreSQL. In part 1, I discussed the work that had already been committed as of that time. In part 2, I discussed what I learned at the meeting, and planned next steps. Since then, a considerable amount of progress has been made, so it seems like a good time to revisit the issue.
First, a brief overview. As I understand it, the goal here is to make PostgreSQL act as a user-space object manager for SE-Linux. In other words, PostgreSQL would manage access to SQL objects by applying SE-Linux access control rules in much the same way that the kernel manages access to files by applying access control rules. As things stand today, SE-Linux can easily prohibit direct access to the underlying data files that ultimately contain the user data; and it can block access to PostgreSQL across the board. What it can't do - because it has no visibility into what PostgreSQL is doing internally - is allow access to some PostgreSQL database objects, but not others.
With that background, let's look at what's been committed over the last few months. All of these patches are the work of KaiGai Kohei, with varying levels of review and clean-up by me.
1. Add a SECURITY LABEL command. In order to reach the goal described above, each PostgreSQL database object must have a security context (just as each file in the filesystem does). These security contexts must be reliably associated with the corresponding SQL objects. Efficiency aside, this pretty much precludes storing them outside the database, since there would be no way to make sure that a label got properly cleaned up when an object is dropped. A subsequently created object might have the same name or OID is the dropped object, leading to a security vulnerability. The SECURITY LABEL command provides a way to associate labels with database objects.
2. Object access hook framework, with post-creation hook. This hook makes it possible for a plug-in module, such as an eventual SE-Linux plugin, to gain control just after the creation of a new SQL object. This hook is intended to be suitable for the assignment of an initial security label to an SQL object. It likely also has other applications.
3. Allow plugins to suppress inlining and hook function entry/exit/abort. This hook makes it possible for a plug-in to suppress the inlining of certain functions and to gain control when execution starts and ends. This is intended to support the SE-Linux concept of a "trusted procedure", which is analogous to the PostgreSQL concept of a security definer function or the traditional UNIX concept of setuid execution. An eventual SE-Linux plug-in for PostgreSQL will need to track the notional security context under which SQL statements are executing. Initially, this will be derived from the security context of the connecting client; however, within a trusted procedure, and as defined by the system security policy, the context can temporarily change to some other value. A trusted procedure could be used, for example, to give a user with "confidential" clearance access to some "top secret" data but with certain details obscured, or with reduced precision.
Taken together, I believe that these patches should provide much of the infrastructure needed for a basic SE-Linux integration for PostgreSQL, which KaiGai Kohei is now working on. It remains to be seen whether the facilities that we now have are sophisticated enough for real-world use cases, but I think we've made some good progress. I'm looking forward to seeing a patch that actually makes use of the hooks we've added so far, and hoping that once we have such a patch it will become more clear what still needs to be done to create a first class system.
Input from the SE-Linux community, or from potential users of this module, would be extremely helpful as we attempt to move forward.