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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
