Adding support for SE-Linux security
in [PgSql]
|
From: Joshua Brindle on 11 Dec 2009 09:34 Stephen Frost wrote: > Tom, > <snip> >> The >> proposals to make SEPostgres drive regular SQL permissions never came >> out of anyone from that side, they were proposed by PG people looking >> for a manageable first step. > > I do not believe this to be accurate. Josh, were you able to find any > public documentation on Trusted Rubix (is that the right name?)? The > RDBMS security policy hashed out on the SELinux list during the > discussion of Rubix and SEPG certainly included support for table-level > objects, did it not? I expect that the SELinux list contributors would > have pointed out if they didn't feel that was at all valuable. Trusted RUBIX does use the same SELinux object classes and permissions that were originally added to the policy to support SEPostgreSQL. You can look at <http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf> and see how they use SELinux in their RDBMS. Pay particular attention to page 15 where they are saying which object classes and permissions they are using. They even implement row level security (the db_tuple object class) > > Perhaps what is at issue is the terminology being used here though, or > the approach to enforment being considered. Part of the discussion at > the BWPUG meeting involved the option for SEPG to be a "more-restrictive > only model" in it's implementation. Essentially, this means that all > permissions handling is done the same as it is today, except that once > the PG model has decided an action is allowed, SEPG kicks in and does > any additional checking of the action being requested it wants and may > deny it. > > At the end of the day, I don't feel that it really changes the > architecture of the code though. Perhaps users of SELinux will always > want that, but the argument we've heard time and time again here is that > this should be a generalized approach that other security managers could > hook into and use. To do that, I feel we first have to start with the > PG model, which *does* care about all the SQL permissions. Let's > extract the various complaints and concerns about SELinux that have been > thrown around this list and instead consider our first "client" of the > PG modular security framework to be the existing PG SQL permissions > system. If we can agree to that, then it's clear that we can't just > hand-wave the requirement that it be capable of driving the regular SQL > permissions. > >> Whatever you might believe about the >> potential market for SEPostgres, you should divide by about a hundred >> as long as it's only an alternate interface to SQL permissions. See >> particularly here: >> http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security >> "Without it, it's questionable whether committing the existing >> stripped-down patch really accomplishes anything" --- how much >> clearer can they be? > > Again, let's please address row-level security first at the PG level. > That was recommended previously by many on this list and is clearly a > useful feature which can stand alone in any case. > >> If you're not prepared to assume that we're going to do row level >> security, it's not apparent why we should be embarking on this course >> at all. And if you do assume that, I strongly believe that my effort >> estimate above is on the optimistic side. > > I do assume we're going to do row level security, but I do not feel that > we need to particularly put one in front of the other. I also feel that > SEPG will be valuable even without row-level security. One of the > realms that we discussed at BWPUG for this is PCI compliance. I'm > hopeful Josh will have an opportunity to review the PCI compliance > "cheat-sheet" that I recall Robert Treat offering and comes to agreement > that SEPG w/o row-level security would greatly improve our ability to > have a PCI compliant system backed with PG. > > Thanks, > > Stephen -- 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 Smalley on 11 Dec 2009 09:37 On Fri, 2009-12-11 at 09:20 -0500, Robert Haas wrote: > On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> Robert Haas <robertmhaas(a)gmail.com> writes: > >>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >>>> My guess is that a credible SEPostgres offering will require a long-term > >>>> amount of work at least equal to, and very possibly a good deal more > >>>> than, what it took to make a native Windows port. > >> > >>> The SEPostgres community is surely a lot smaller than the Windows > >>> community, but I'm not sure whether the effort estimate is accurate or > >>> not. If "credible" includes "row-level security", then I think I > >>> might agree, but right now we're just trying to get off the ground. > >> > >> It's been perfectly clear since day one, and was reiterated as recently > >> as today > >> http://archives.postgresql.org/message-id/4B21757E.7090806(a)2ndquadrant.com > >> that what the security community wants is row-level security. The > > > > If that is true, then shouldn't we have an implementation of row level > > security *first*, and then an implementation of selinux hooks that > > work with this row level security feature? Rather than first doing > > selinux hooks, then row level security, which will likely need new > > and/or changed hooks... > > > > I'm not convinced that row level security is actually that necessary > > (though it's a nice feature, with or without selinux), but if it is, > > it seems we are approaching the problem from the wrong direction. > > I don't think there's a correct ordering to SE-PostgreSQL and > row-level security. They're better together, but I don't think either > has to be done first. If we were going to pick one to do first, I'd > pick SE-PostgreSQL. Row-level security is going to be a @$#! of a > project if we want it done right (and we do). I'm not sure it is a strong analogy, but as an example, in the case of Linux, we started by integrating support for a base set of access controls over directories and files, and only later introduced support for multi-level/polyinstantiated directories by building upon Linux's per-process filesystem namespace construct. The base set of access controls for directories and files were certainly useful on their own even before we had the support for polyinstantiated directories. In any event, I would agree that support for applying MAC over the database objects and operations is useful even without row-level security, although ultimately we would like both. -- Stephen Smalley National Security Agency -- 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 10:07 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 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. 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. > > 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? 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. 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: Stephen Frost on 11 Dec 2009 10:24 Magnus, * Magnus Hagander (magnus(a)hagander.net) wrote: > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > It's been perfectly clear since day one, and was reiterated as recently > > as today > > http://archives.postgresql.org/message-id/4B21757E.7090806(a)2ndquadrant.com > > that what the security community wants is row-level security. The > > If that is true, then shouldn't we have an implementation of row level > security *first*, and then an implementation of selinux hooks that > work with this row level security feature? Rather than first doing > selinux hooks, then row level security, which will likely need new > and/or changed hooks... The proposal we're currently grappling with is to pull all the various checks which are sprinkled through our code into a single area. Clearly, if that work is done before we implement row-level security, then the patch for row-level security will just add it's checks in the security/ area and it'd be then easily picked up by SELinux, etc. > I'm not convinced that row level security is actually that necessary > (though it's a nice feature, with or without selinux), but if it is, > it seems we are approaching the problem from the wrong direction. It has to be implemented independent of the security/SELinux/etc changes in any case, based on what was said previously.. So I don't particularly understand why it matters a great deal which one happens first. They're independently useful features, though both are not nearly as good on their own as when they are combined. Sorry, I just don't see this as a "cart-before-the-horse" case. Thanks, Stephen
From: "David P. Quigley" on 11 Dec 2009 10:24
On Fri, 2009-12-11 at 08:56 -0500, Stephen Frost wrote: [snip...] > I do assume we're going to do row level security, but I do not feel that > we need to particularly put one in front of the other. I also feel that > SEPG will be valuable even without row-level security. One of the > realms that we discussed at BWPUG for this is PCI compliance. I'm > hopeful Josh will have an opportunity to review the PCI compliance > "cheat-sheet" that I recall Robert Treat offering and comes to agreement > that SEPG w/o row-level security would greatly improve our ability to > have a PCI compliant system backed with PG. > 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. The requirements in section 7 can definitely benefit from SEPG. If you implement these requirements in the application server and in PG access controls alone there is still an attack vector where a malicious user manages to steal the credentials for a particular role. With PG-ACE you can write a security module (although SEPG already allows for this) to restrict access to the data using the existing role-based access controls in PG and then apply additional restrictions such as, only this program may act as this role or access this database. This provides better guarantees than exist in current PCI compliant implementations using PG today. 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 |