In part 1 of this blog post, I talked about my recent visit to BWPUG to discuss SE-Linux and PostgreSQL, and reviewed the work that has been done so far, as well as a few upcoming patches. In this second part of the post, I'm going to review what I learned at the meeting and where the SE-Linux folks told me they'd like to see us go with this.
One of the most interesting concepts we discussed was the idea of a type transition. This may be old hat for experienced SE-Linux users, but it was a new idea for me. I'm not sure that I understand this concept in its full generality, but Joshua Brindle explained two specific applications of it to me. First, when objects are created, SE-Linux apparently allows the context of that object to depend not only on the context of the creator, but also on where the object was created. For example, if Apache is running in a context called apache_t and creates a temporary file in /tmp, the context of the new file might be apache_tmp_t. Similarly, if a PostgreSQL client creates a table, the SE-Linux folks would like to be able to determine the security label for the table based on a combination of the client's context and the containing schema's label.
The second application of type transitions which we discussed in the meeting related to what KaiGai Kohei has been calling a trusted procedure. The idea here seems to be that when a certain function is executed, SE-Linux should have the option based on the user's context and the function's context to transition to a new security context for just the period of time during which the function is executing. This doesn't involve a kernel call: it's just internal recordkeeping. I'm imaging that SE-Linux support for PostgreSQL will be provided by a loadable module, so essentially we'd need a bullet-proof way of allowing the SE-Linux module to gain control briefly at function entry and exit time (and that would be certain to be called even if, say, we exit the function due to an error condition).
We also talked about SE-Linux control of operations other than DML, which is what the ExecCheckRTPerms hook I talked about in part 1 of this posting will support. In particular, Joshua Brindle and David Quigley were very concerned about proper control over the LOAD statement. It looks like this can be easily accomplished using the existing ProcessUtility_hook. They were also concerned about DDL, but again it seems like the existing ProcessUtility_hook would be sufficient to impose coarse-grained restrictions. Ultimately, that may not be the best way to go forward, as it may not provide easy access to all the bits they care about - in particular, I think we will need one or more special-purpose hooks in ALTER TABLE - but it may be enough to do something crude.
Another very large hole that will need to be plugged is control over large objects. These will need security labels and appropriate access checks.
Finally, the SE-Linux folks indicated that in the long run they would really like to have row-level access control, but they believe that they can accomplish useful things with an implementation which does not include that capability, as long as they have the "trusted procedure" facility discussed above.
I'm not sure how far we're going to get with this work during the PostgreSQL 9.1 time frame. KaiGai Kohei has poured a tremendous amount of time into this work over the last several years, but progress has been slow. I think one of the big reasons for that is that doing this work in a way that is acceptable to the PostgreSQL community can sometimes require significant refactoring of the existing code. It's not always obvious how to accomplish that, and many of the people who are in the best position to carry it off successfully can't put a lot of time into it unless there is funding attached. So far, no one stepped forward in this area; if that changes, I expect to see much more rapid progress.