Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> One of the major and fundamental stumbling blocks we've run into is
> >> that every solution we've looked at so far seems to involve adding
> >> SE-Linux-specific checks in many places in the code.  It would be nice
> >> if it were possible to use the exist permissions-checking functions
> >> and have them check a few more things while they're at it, but it's
> >> looking like that won't be feasible, or at least no one's come up with
> >> a plausible design yet.
> >
> > I don't think that it's about SELinux.  The real issue here is that
> > KaiGai-san is about a mile out in front of the PG hackers community
> > in terms of his ambitions for the scope of what can be controlled by
> > security policy.  If the patch were only doing what the community has
> > actually agreed to, there would be little need for it to touch anything
> > but the aclcheck functions.
> >
> > Now I recognize that a large part of the potential attraction in this
> > for the security community is exactly the idea of having fine-grain
> > security control.  But if you ever want anything significantly different
> > from SQL-standard permission mechanisms, there's going to have to be a
> > whole lot more work done.  Basically, nobody in the PG community has got
> > any confidence either in the overall design or the implementation
> > details for locking things down that aren't already controlled by SQL
> > permission mechanisms.
> 
> I think that's basically right.  Further, I think this is basically a
> resource issue.  If you were inclined to spend a large amount of your
> time on this problem, you could either gain confidence in the present
> design and implementation or come up with a new one in which you did
> have confidence.  But it doesn't seem important enough to you (or your
> employer) for the amount of time it would take, so you're not.  I
> think there are other committers and community members in a similar
> situation - basically all of them.
> 
> ...Robert
> 


I have to agree with Chad (downthread) that I don't see much in KaiGai's
hook patch that prevents its use by other security models. I will say
though one thing that might have been done wrong was with how it was
presented. In actuality his patch set is two projects (at least). The
first is the framework. So I think the goal should have been to get the
framework integrated first and then work on the SELinux module after
that. The framework patch alone consists of at least 4 sets of logical
changes that could have been separated to make review easier. Once the
framework was in, work could be done to get the SELinux module in while
reducing overhead from the case where no module is loaded.

So with regard to confidence in the design I think that part of the
reason for the skepticism in the fact that it was such a large code
drop. Even the separated parts were very large. I think if the framework
patches are broken up more logically and in a way that is easier to
discuss then that might help the community get a grasp on what it is
trying to accomplish. 

In terms of documentation I was reading through the wiki at
sepgsql.googlecode.com and aside from some wordsmithing/grammar things
it is pretty solid with describing what it is trying to accomplish. One
problem that I see is that at first glance it does appear to be very
SELinux centric. It describes access based on types and SELinux contexts
which is understandable based on the fact that it describes the
framework and the module. Something to note is that the documentation
describes an object model for the program. I think that would be a good
place to focus the discussion with respect to a framework if we decide
to pursue it.

Dave