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

On Fri, 2009-12-11 at 11:16 -0500, Stephen Frost wrote:
> David,
> 
> * David P. Quigley (dpquigl@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