Re: 8.4 release planning - Mailing list pgsql-hackers

Joshua Brindle <method@manicmethod.com> writes:
> http://marc.info/?l=selinux&m=115762285013528&w=2
> Is the original discussion thread for the security model used in the 
> sepostgresql work. Hopefully you'll see some of the evidence you speak of there.

Thanks for the link.  I took a look through that thread and saw a lot of
discussion about issues like how to relate the database-side and
client-side permissions, which is all good stuff but mostly outside my
purview as a database geek.  I didn't find anything about the stuff that
is really bothering me, which I think can be broken down into two main
categories:

1. Silently filtering out rows according to an arbitrary security policy
can break a bunch of fundamental SQL semantics, the most obvious being
foreign key constraints --- an application might be able to see a
dependent row that apparently has no referenced row, or might get an
update or delete failure for a row that is unreferenced as far as it can
see.  Things get worse if an application can insert, update or delete
rows that it can't select.  The only answer I've been able to get about
what SEPostgres will do about that is "we really don't care that we're
breaking SQL semantics".  I don't find that to be a satisfactory answer.
The security-geek reason why not is that it represents a huge
information leak.  The database-geek reason why not is that this will
permanently destroy our ability to do a lot of important optimizations,
eg join removal on the basis of foreign key constraints.  (There are
probably other good reasons, but that one will do for starters.)
Perhaps this is fixable by constraining what a security policy is
allowed to do, or in some other way that I don't know about, but I've
seen no serious discussion about that.

2. I don't understand where to draw the dividing line between database
system accesses (which can't be security constrained, at least not
without breaking things entirely --- eg it will do you little good to
imagine that you can hide rows in pg_security from the
security-enforcement code ;-)) and user accesses that should be
security-constrained.  I am certain that the line is muddied beyond
usability in the current system; there are a lot of user-exposed
functions that are making use of the same infrastructure that core
system accesses do.  As an example, some of the people who think they
want this feature would like to use it to hide the bodies of their
user-defined functions from other people whom they don't wish to see
their code.  But pg_get_functiondef() uses the same catcache
infrastructure as the code that would be called on to actually execute
their function, so there is no reasonable place to prevent the function
body from being exposed through that inquiry function or others of its
ilk.  This problem gets rapidly worse when you consider that Postgres is
designed to be a very extensible system.  It's not clear how to classify
add-on code, and it is clear that any of it could unintentionally
introduce a security hole.  The only solution I can see is "we stop
guaranteeing that SEPostgres is good for anything the moment you load
even one extension module", and that isn't a very satisfactory answer
either.  Even accepting such a restriction, there's too much code in
core Postgres to let anyone feel very good about keeping the core free
of security leaks.

There are some other problems, like the rather frightening thought that
a database dump might silently omit critical data (remember pg_dump is
just another client).  But I think the two categories above cover the
issues that are making me seriously leery of this patch.
        regards, tom lane