Tom Lane wrote:
Joshua Brindle <met...@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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
