Adding support for SE-Linux security
in [PgSql]
|
From: Stephen Frost on 11 Dec 2009 11:16 David, * David P. Quigley (dpquigl(a)tycho.nsa.gov) wrote: > So I downloaded and read through the PCI DSS document (74 pages is > pretty light compared to NFSv4.1 hehe...) and There are several areas > there where I think strong access controls in the database will not only > fulfill the requirement but provide much stronger guarantees than can be > provided from the application server alone. Thanks for taking a look! That sounds like excellent news. My apologies for attributing the action item to the wrong individual. :) > The requirements in section 7 can definitely benefit from SEPG. I don't mean to be a pain, and we're all busy, but perhaps you could include a short description of what 'requirements in section 7' are.. It would help keep the mailing list archive coherent, and be simpler for folks who aren't familiar with PCI to play along. A link to the specific PCI DSS document you looked at would be an alternative, tho not as good as a 'dumbed-down' description. ;) That would at least avoid confusion over which document, since I presume there's more than one out there. Thanks again for looking over this! Treat, you've dealt alot with PCI in your commercial work; could you comment on this for the benefit of the list? I don't doubt David in the least, but it never hurts to have someone as lucky as yourself in frequent dealings with PCI compliance to provide any additional insight. Thanks! Stephen
From: Stephen Frost on 11 Dec 2009 11:28 * David P. Quigley (dpquigl(a)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.1255627322(a)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
From: Robert Haas on 11 Dec 2009 11:30 On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley <dpquigl(a)tycho.nsa.gov> wrote: > On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote: >> 2009/12/11 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: >> > It tried to provide a set of comprehensive entry points to replace existing >> > PG checks at once. >> > However, the SE-PgSQL/Lite patch covers accesses on only database, schema, >> > tables and columns. Is it necessary to be comprehensive from the beginning? >> > It might be too aggressive changes at once. >> > >> > Frankly, I hesitate to salvage the patch once rejected, as is. >> > >> > If we implement a set of security hooks, It seems to me the following approach >> > is reasonable: >> > >> > * It does not touch the existing PG default checks. >> > The purpose of security hooks are to host "enhanced" security features. >> > >> > * It does not deploy hooks on which no security provider is now proposed. >> > It is important to reduce unnecessary changeset. >> >> 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. I am not sure who "Steve" is or which patch you're talking about, but suffice it to say that I think the problem you are articulating here is exactly the one we need to get out from under. I don't know how to do that yet and... > They may have been said before but what exactly are the design issues? ....that's the design issue I think we need to surmount. I think it will be easier to talk through that with a mini-patch that only affects one object type. I'll stop here because I see that Stephen Frost has just sent an insightful email on this topic as well. Hmm, maybe that's the Steve you were referring to. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 11 Dec 2009 11:40 * Robert Haas (robertmhaas(a)gmail.com) wrote: > I'll stop here because I see that Stephen Frost has just sent an > insightful email on this topic as well. Hmm, maybe that's the Steve > you were referring to. I have doubts- but then I don't ever see my comments as insightful for some reason. ;) Thanks! Stephen
From: "David P. Quigley" on 11 Dec 2009 12:06
On Fri, 2009-12-11 at 11:28 -0500, Stephen Frost wrote: [snip...] > > 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. So we contacted Casey about another MAC model for PG using PG-ACE and he got back to us with these reponses. Josh Brindle (JB): So my question is, does smack have a facility for userspace object managers? Casey Schaufler (cs): Yes. The smack-util package includes a small library which supports a user space version of the kernel smackaccess() function. You pass it the subject label, object label, and desired access and it returns a yes/no answer based on what it reads from /smack/load. So this answers our questions on whether or not SMACK has the faculties to act as the security decision engine for PG. JB: If so, I want to make the argument that doing a smack integration using the pgace abstraction layer would not only work but be fairly easy. CS: Looking at some of the documentation I think that you can safely make that argument. The security_label column would just be the Smack label. The rules can be enforced by the user space smackaccess(). "System" rows, whatever that might be, could get the floor ("_") label. Casey mentions the row level access control in here but its safe to say we've broken row based access control into a followup discussion/project. JB: All the sepgsql docs and code are up at <http://code.google.com/p/sepgsql/> and I'd like to get your feedback before I start making claims... CS: I can't see how it would take more than about a day if pgace does what it looks like it should. This seems to be a favorable assesment of the pgace framework's ability to be used by something other than SELinux. So Casey's Smack module plus the Sun guys saying it is usable by their legacy TSOL or TX code would lend credence to the idea that pgace is bringing to the table. It may be possible that you're not happy with certain aspects of the implementation but the objects and permissions listed in pgace are definitely ones that are worth mediating. Dave Dave -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |