Re: 8.4 release planning - Mailing list pgsql-hackers

Sorry for long description.

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

As I repeated it several times, it is a "covert channel" issue.
An important thing is what the limilation is well documented and
allows end-users to choose the option.
As I summarized in another message, it is not a must-requirement
for security evaluation criteria (ISO/IEC15408, CC).
The criteria allows to include a feature to eliminate covert channels,
but it also allows not to include ones to eliminate them. http://wiki.postgresql.org/wiki/SEPostgreSQL#Covert_channels

For example, Oracle Label Security which is certified as EAL4+ class
and also provides row-level mandatory access controls, but it does not
care about covert channels. This fact is documented as "Security Target",
so end-users can know that elimination of covert channel is over spec
for the product.
They can choose the product with their own responsibility.

At first, we should understand is individual security features have
its own targets, coverages and so on.
I assumes the target of SE-PostgreSQL is enterprise class users
who are interested in web application security like a cloud-computing
platform, similar to Oracle's one.

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

IIRC, we had discussions refering to ISO/IEC15408 a few times at the
past. I believe it was serious discussions.
Polyinstantiation technology might help the situation, but we decided
not to port it on PostgreSQL due to widespread unacceptable changes.

I make clear it again.
It is an over spec for SE-PostgreSQL to eliminate all the covert channels,
however, we documented the limitation for end-users, and they can choose
SE-PostgreSQL with their own responsibility.


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

Please consider the symmetrical architecture between OS and DBMS.
A process accesses resources managed by OS via system calls, and
SELinux acquire the system calls and applies its decision making.
In other hand, a client accesses database object managed by DBMS
via SQL queries, and SE-PostgreSQL applies its decision come from
security policy of SELinux.

Please note that SELinux cannot apply its security policy on
accesses come from in-kernel code in principle, although it
enables to control kernel-loadable-modules.
In same manner, SE-PostgreSQL cannot apply its access controls
on internal database system accesses.

It come from characteristics of a reference monitor which applies
its security policy for all the required accesses, but internal
steps are exceptions.

For example, if SELinux allows a malicious one to load a kernel
loadable module which hijacks filesystems, any other users have
a possibility to invoke the malicious code indirectly which
can bypass SELinux's checks.

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

In this case, security administrator should not allow unprivileged
users to invoke pg_get_functiondef(). User invokes pg_get_functiondef()
via SQL queries, but pg_get_functiondef() refers system cache via
its internal process.

For add-on module, SE-PostgreSQL checks whether the client has
db_database:{install_module} privilege on the target database
and installed module (on the filesystem).

I would like to make clear I have never said it is possible to
prevent malicious accesses from system internal entities.

As you mentioned before, it is not fundamentally possible.
Do you remember a previous discussion you suggested to remove
the pgaceAllowOverridePlannerHook() hook and I agreed soon?

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

Forgive me, it seems to me you concern about SE-PostgreSQL is not
a magic-ballet of security. However, we never guarantee it enables
to protect malicious anything. Any security features have its merits
and limitation, needless to say. SELinux is not also perfect.
(At least, who can prove it is perfect?)

Information-Security has a long history more than 2,000 years since
the period of Caesar-cipher, but mankind has not see perfect security
yet. Thus, we need to improve it step by step.

I would like you to understand not negligible number of users are
waiting for SE-PostgreSQL feature, even if these limitations.


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

As I documented, a client runs pg_dump/pg_restore should have enough
privileges on whole of the databases.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>