Adding support for SE-Linux security
in [PgSql]
|
From: "David P. Quigley" on 11 Dec 2009 12:25 On Fri, 2009-12-11 at 11:16 -0500, Stephen Frost wrote: > 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. :) Nahh you attributed it to the correct person I just got a little bored yesterday and poked my nose into it :) > > > 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. So the document I read is linked below [1]. Requirement 7 falls under "Implement Strong Access Control Measures". The two main requirements under requirement 7 seem to be "limit access to system components and card holder data to only those individuals whose job requires such access" and "Establish an access control system for systems components with multiple users that restricts access based on a user's need to know, and is set to “deny all” unless specifically allowed." The major flaw with this system is that stolen credentials allow you to completely bypass the logic for this in the application layer. If the person manages to get the login and password for an account on the database it doesn't matter what their authenticated use is because the logic to prevent accountant bob from cutting his own payroll check is in the application layer. The way that MAC controls can strengthen the protections by making sure that only certain components can perform certain actions. If you want to make sure that only the accounting application can mess with that data regardless of whether you have the database credentials or not then you can do that. You can write policy for SEPG to say only programs with this label can perform these actions on the database. Only applications labeled with the accounting_tool label can modify the table labeled accounting_data. This way if the system is compromised and someone manages to get the username and password for the database account/role that you were protecting the table with since the request isn't coming from a process labeled accounting_tool the database will deny those accesses. This is why I mean by adding stronger protections. This way you've minimized the amount of code that you have to accredit for compliance in your application server. [1] https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf > > 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. It is definitely good to have a second opinion on this since I've just only started reading the PCI compliance documents. I'm definitely not an expert in PCI compliance but from what I've read there are definite benefits for using SEPG or PG-ACE with a special security module in making much stronger guarantees about who and what can touch the card data. 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
From: "David P. Quigley" on 11 Dec 2009 13:17 On Fri, 2009-12-11 at 11:30 -0500, Robert Haas wrote: [snip...] > > 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 > Yea I never asked Stephen if he goes by Stephen or Steve when I met him on Wednesday. I guess calling him Steve is me being a bit presumptuous :) -- 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 15:06 David, * David P. Quigley (dpquigl(a)tycho.nsa.gov) wrote: > So the document I read is linked below [1]. Great, thanks again. [agree with all the rest] > It is definitely good to have a second opinion on this since I've just > only started reading the PCI compliance documents. I'm definitely not an > expert in PCI compliance but from what I've read there are definite > benefits for using SEPG or PG-ACE with a special security module in > making much stronger guarantees about who and what can touch the card > data. Indeed. The other nice piece about getting the opinion of Treat (or others who have to deal with PCI) is that while the PCI documentation says what you're supposed to do, the PCI folks also have auditing requirments (as in, a third-party vendor has to audit your system, and there are required scans and scanning tools, etc) which don't always marry up to what they say they require. Thanks! Stephen
From: Stephen Frost on 11 Dec 2009 15:09 * David P. Quigley (dpquigl(a)tycho.nsa.gov) wrote: > Yea I never asked Stephen if he goes by Stephen or Steve when I met him > on Wednesday. I guess calling him Steve is me being a bit > presumptuous :) Oh, either is fine, tho people will probably follow a bit better if you say "Stephen". As a reminder- KaiGai's the one who did all the actual code, I just tried to steer him in a direction I thought made sense to make it easier to get core to accept it, and reviewed the results of his work. Thanks! Stephen
From: Robert Haas on 11 Dec 2009 15:14
On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost(a)snowman.net> wrote: > Second, the information we *don't* have from above is generally > information about what the requesting action is. For example, when > changing ownership of an object, we can't possibly use introspection to > find out the role which is on the receiving end, since at that time > we've just learned it from the parser. I'm not sure that I follow what you're saying here. I think maybe it would help to discuss a concrete example, which is why I proposed a concept patch. Or perhaps you'd like just to pick out a specific case to discuss. > Now, we might build an entire > new object, pass the "result of this action" OID to the security system > and ask it "can we change OID X into OID Y?", but I don't particularly > like it. We really don't want to do any *changes* to things until after > we've determined the permissions allow for it, and I'm not sure how to > get around that without building an independent introspection system for > "what might be". Perhaps we're comfortable enough saying "we'll just > rollback the command if it turns out to have not been allowed" but I > just don't like it. Feels like a higher risk solution to me. Yeah, that seems like a non-starter. > I don't see a way to get around the second piece since what information > is needed about the action is typically action-specific. Perhaps we > could have an 'action-ID' (uh, we have an ID per command already, no? > Probably doesn't fit the mold close enough though), and then a way to > query information about "what is this action trying to do?". Doesn't > seem likely to be very clean though. Object creation seems to be one of the tougher cases here. When you're altering or dropping an existing object, the decision is likely to be based (in any system) on the properties of that object. When you're creating an object, the decision will of course have to be based on the properties of something else, but different access control models might not agree on the value of "something else". It's not immediately clear to me how to deal with that, but again it's hard for me to discuss it in the abstract. ....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 |