Re: 8.4 release planning - Mailing list pgsql-hackers

Tom Lane wrote:
> 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

This is correct. Strange error conditions can happen when you are using 
mandatory access controls. The same thing happened in linux when selinux was 
introduced. There was plenty of code out there that assumed if it was running as 
root it could do anything. Lots of it didn't even check for error conditions. 
The existence of poorly written applications should never be an argument against 
adding security.

> 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

Because type enforcement (the primary mechanism behind selinux) is very flexible 
it is true that policy writers have plenty of rope to hang themselves with. We 
can only attempt to educate and document these issues, blocking out security is 
not a satisfactory answer.

> 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.

Plenty of people feel the same way about SELinux (or any mandatory access 
controls). That is why there are options, if you want this security and don't 
care if your applications puke then enable it, else disable it. Noone is going 
to force you to use this, right?

> The security-geek reason why not is that it represents a huge
> information leak.  The database-geek reason why not is that this will

The great thing about security is that, by itself, it actually doesn't mean 
anything. Security is where you are willing to balance between stopping people 
from getting something done and letting them get something done. In this case, 
removing all covert channels would not only be impossible but it would make an 
unusable database system. In SELinux we didn't worry about covert flows, 
(actually we ignored/documented plenty of overt flows as well). With something 
as complex as the Linux kernel or an enterprise rdbms it is nearly impossible to 
eliminate such things.

People who need absolute separation of information already have options, 
multiple server processes, polyinstanciated views, etc. For people that don't 
care if someone can see that you've inserted a couple rows since the primary key 
got larger, or can tell that an associated row that isn't visible exists in 
another table a more flexible, yet still mandatory system like sepostgresql is 
the answer.

The great thing about this work is that, in many cases, a well designed system 
(that is, well designed for the security policy it is going to be constrained 
under) should not be impacted greatly by these issues. If a client needs 
information where they can't see all of the associated rows you can have trusted 
stored procedures (which run in a different selinux context, as defined by a 
type transition from the client context) that do the work and return the 
appropriate results. I know you can't use stored procedures for everything but 
they'd go a long way in binding queries we trust to the data they expose (just 
like in SELinux we bind binary code on the filesystem to domains that code can 
be used to enter)

> 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.
> 

KaiGai already talked about the permissions he's added to prevent user functions 
from being inserted. This is in the same class as in SELinux where we can't stop 
you from taking over the machine and disabling SELinux if you can insert kernel 
modules so we'll control the insertion of modules and if a policy writer allows 
it then so be it.

> 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.
> 

pg_dump, just like a backup agent on an SELinux machine would have to have read 
access. Backup applications are generally considered trusted applications.