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

From David P. Quigley
Subject Re: Adding support for SE-Linux security
Date
Msg-id 1260312175.2484.228.camel@moss-terrapins.epoch.ncsc.mil
Whole thread Raw
In response to Re: Adding support for SE-Linux security  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > PGACE wasn't a plugin system.  It was an API inside the core code.  If
> > it had been a plugin system, this would have been much easier, because
> > the plugin itself could have been developed independently.
> 
> Well, it should certainly have used function pointers or something to
> allow better pluggability, but that would have been a trivial change.
> I don't believe that doing so would have made development any easier.
> The real problem in all this is to answer the question "do we have the
> right hooks in the right places?".  Whether the hooks lead to function
> pointers or hard-wired calls doesn't enter into that.  Moreover, since
> we can confidently say that all the early answers will be "no", it would
> be a serious mistake to try to develop the plugin independently.
> Having to keep two independent sets of source code in sync would waste
> a lot of effort every time you realized you needed to adjust the hook
> definitions.  Once you'd gotten to a releasable state maybe you could
> assume the hook definitions would become stable, but right now I have no
> confidence in that at all.
> 
>             regards, tom lane
> 

I disagree with several of your statements above. While the question of
whether or not the hooks are in the right place is up for debate what
the hooks should be is something that I think has been explored pretty
well. The hooks should reflect the object model. Where you need to put
them to enforce permission is a different story. 

Also maintaining a module and a framework is not a waste of time. If
your security module has a tremendous code churn when the interface to
the program is modified you should reevaluate your design. Both SELinux
and the Flask X-ACE modules are examples where an existing extension had
a modular framework developed after the fact and easily integrated into
the project. The majority of the work is moving to a framework not
changing function prototypes in code that's already in the framework.

Dave 



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: tsearch parser inefficiency if text includes urls or emails - new version
Next
From: KaiGai Kohei
Date:
Subject: Re: Adding support for SE-Linux security