Re: SE-PostgreSQL and row level security

A couple of thoughts:
First off, I think the inclusion of row level security and an
unprecendented integration with OS level security are a stunning
example of what makes Open Source so much cooler than closed source
products. Great job! (and the speed of refactoring the patches was
pretty stunning as well)

My two cents on some of the debates going on...

1. Row level security is a useful security feature (just as are
encryption, statistical fuzzing and others). Successful database
security will still require careful thought and design. This is
particularly true when users require "ad-hoc" query access with
commercial tools whose security implimentation may or may not be
adequate.
2. It is not reasonable to expect SE-PG to be the answer to every
security issue. There are almost always ways to extract SOME
information. The proposed features are just additional tools for
helping to enforce a chose security policy.Please note the "VPD"
feature of oracle returns security related errors in such a way that
it is sometimes possible to extract information from which actions
provoke security errors versus no error.
3. The integration with the OS and file system security is neat, but
for most databases, the users of the database do NOT have ANY access
to the machine the database resides on other than through the
database. But as I said it is neat and symmetrical in a way commercial
product rarely are. So seperating out row level security makes a lot
of sense. Good call.
4. There are significant benefits to integrating row level security as
a standard feature of PG that users can switch on/off as needed.
However, the frequent return to the notion of "claims" for SE-PG
concern me a little. One of the key provisions of open source software
is that it imust be essentially "use at your own risk". Designing to
minimize covert channels is worthwhile and useful. Any claim in this
regard is however quite foolish as it would requre extensive
validation and re-validation every time a patch was accepted. This
should be considered carefully.
5. The needs of various communities of users are distinctly different
with respect to security. For many prospective users of row level
security, it is mostly a checkbox as part of an overall effort to
comply with privacy laws or policies to limit liability. For some
users, it is a lot more than that and they expect that there will be
active and well educated attempts to violate security. For an even
smaller subset of users, lives may depend on the effective
compartmentalization of information. These are distinctly different
needs and their needs for features will overlap some but not
completely. The debate over returning a security message when rows are
not returned is a good example of this divergence. A company I did
some work for at one point decided to implement row level security for
their HR information. They were using a technology that returned
security messages, but did not think this was a problem until it was
pointed out that for the most common cases of abusing HR information
(co-workers) the co-worker generally already had access to at least
some of the information in question and returning a security message
allowed a process of elminitation to be used to extract a significant
amount of  data. On the other hand, it was also sometimes necessary to
allow rows to participate in aggregations or there was little point in
having the data. To my knowledge there is no database product that
allows the implementation of a truly comprehensive and effective
security policy without careful design to take these issues into
account (which may in fact require the violation of other "design
rules" to implement).

So, all that said... It hink the answer is to move ahead with SE-PG
but to make it clear that in this first release, the behavior is
subject to change.

- Martin Rusoff


On Mon, Feb 16, 2009 at 12:37 PM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
> On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> With reference to row-level security, most of the complaining about
>> this feature has been along the lines of "I don't like the idea that
>> rows get filtered from my result-set that I didn't ask to have
>> filtered".
>
> yeah! because was filtered by powers above yours... ;)
>
> i thing row level acl it's good feature for those that *really* need
> it, as every other solution this is not for everyone and could and
> will be misused sometimes... as far as the code maintain readibility
> and doesn't interfer in an instalation that doesn't include
> --enable-selinux i'm in favor of including it...
>
>
>> To me, the fact that you didn't have to ask seems like a
>> huge convenience, and I can't imagine why you'd want it otherwise.
>> Sure, the behavior needs to be documented, but that doesn't seem like
>> a big deal.
>>
>
> not only a convenience, it's a way to enforce policies that cannot be
> circumvented easily from programming (if you have very secret info
> that cost a lot, you can start being paranoic even of your own
> developing team ;)
>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



--
Martin Rusoff
614-208-0381
742 Autumn Branch Rd.
Westerville OH 43081