* David P. Quigley (dpqu...@tycho.nsa.gov) wrote: > On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote: > > I think that we should try to move the PG default checks inside the > > hook functions. If we can't do that cleanly, it's a good sign that > > the hook functions are not correctly placed to enforce arbitrary > > security policy. Furthermore, it defeats what I think would be a good > > side goal here, which is to better modularize the existing code. > > So from the meeting on Wednesday I got the impression that Steve already > did this. However it was rejected because too much information was need > to be passed around.
KaiGai did all the work, but it was my suggestion to go down this route and I reviewed KaiGai's patch to do it. The specific 'review/rejection' email is here: http://archives.postgresql.org/message-id/10495.1255627...@sss.pgh.pa.us > I gathered and I could be wrong but the reason for > this is that instead of developing proper abstractions for the security > code people made use of whatever local stuff was available to them at > that location. That's certainly one concern I continue to have, but as I've been rereading the threads I'm less confident it's a huge problem- the issue seemed to be more about the single access_control.c knowing about the entire PG world. > With the X-ACE work that Eamon Walsh did he did exactly > what you're saying. He figured out the object model for the X-Server and > created the hook framework. In the merge of the hook framework he also > moved the existing X server security model into the framework. It's great to hear specific examples of other projects which have gone through this headache and come out the other side better for it. > > What I would suggest is that you develop a version of that patch that > > is stripped down to apply to only a single object type (databases? > > tables and columns - these might have to be together??) and which > > addresses Tom's criticisms from the last time around, and post that > > (on a new thread) for discussion. That will be much easier to review > > (and I will personally commit to reviewing it) but should allow us to > > flush out some of the design issues. If we can get agreement on that > > as a concept patch, we can move on to talking about which object types > > should be included in a committable version of that patch. > > They may have been said before but what exactly are the design issues? Unfortunately, "design" isn't nearly as well defined a term as one would hope. I believe KaiGai's latest suggestion (which is probably what his original PGACE implementation was, but I'm going to avoid looking, the community has enough egg on it's face already wrt this :/) is a good approach, along with splitting the huge access_control.c file into per-object pieces. That's a design change, tho perhaps not the kind of one others who have commented on the design were thinking about when they made those statements. Basically, there's the design of the code layout and how each piece knows about the other pieces (through header files, etc), and then there's the design of the function calls/ABI and actual code paths which are taken when the code is executed (which doesn't particularly care how the code is laid out in the source tree). I feel like the design issues raised have been more about the former and less about the latter. > The main concern I hear is that people are worried that this is an > SELinux specific design. I heard at the meeting on Wednesday that the > Trusted Extensions people looked at the framework and said it meets > their needs as well. If thats the case where does the concept that the > design is SELinux specific stem from? We've asked Casey Schaufler the > developer of another label based MAC system for Linux to look at the > hooks as well and make a statement about their usability. Hope I didn't steal your thunder wrt Casey! Thanks again. Thanks, Stephen
signature.asc
Description: Digital signature
