Tom, * Tom Lane (t...@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.7090...@2ndquadrant.com > that what the security community wants is row-level security.
Yes, they do want row-level security. That being said, KaiGai, and others, have pointed out time and time over again that SEPG without row-level security is still useful. Additionally, I see absolutely no way that PG would accept a full SEPG+PGACE+row-level security, etc, patch in as one whole patch, ever. I have extreme doubt it would even be something done over one *release*. That all aside, for the moment, I feel that we should begin a 'two-prong' attack here. First, continue down the path that I've started to lay out for SEPG. Second, let's hash out a design for row-level security using the existing PG security model; ideally using the best features and design decisions of the numerous row-level security systems already implemented by the major SQL vendors today. I'll start a new thread on this specific topic to hopefully pull out anyone who's focus is more on that than on SEPG. > 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. 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
signature.asc
Description: Digital signature
