Re: [PATCH] SE-PgSQL/tiny rev.2193

Martijn van Oosterhout wrote:
> On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
>>>> Specifically, creating SELinux permissions for CREATE LANGUAGE seems
>>>> particularly useless since that's not a data protection issue. The same
>>>> with aggregates, operator classes, etc. ISTM the goal of SELinux is not
>>>> primarily to restrict DDL but mostly to protect the data.
>> The reason for comprehensively protecting objects isn't necessarily about
>> protecting the data in the database but for limiting information flow
>> between clients of differing security levels. Eg., if someone top secret
>> can create language and use that to pass information down to someone
>> unclassified then postgres could be used as an information downgrader
>> illegitimately.
>
> Consider the pl/pgsql language. The creation of the language must be
> protected, because it involves loading shared libraries and thus could
> be used to bypass the system. However, once loaded the language only
> uses the internal SQL interface and thus is subject to the restrictions
> imposed by the caller (except for setuid functions ofcourse).
>
> Would you agree if the language is transparent with respect to
> permissions that *usage* of the laguage doesn't need to be restricted.
>

Using something is typically controlled because of information you may get from
using it (for example, stat() on a file may not get you the data in the file but
it gets you plenty of other information). I guess the question is, can the
person creating the language leak information to people using the language and
it sounds like they can.

However, because language creation is controlled via superuser privilege (which
is never ideal, we like to be able to break superusers up and give them only
permission to do what they need to do, principle of least privilege) then it is
probably a lot less important than many of the other things KaiGai is trying to
get in.

> I'm asking because from my position it looks like KaiGai is being
> simultaneously told "you patch is too big, make it smaller" and "your
> patch is not complete (with respect to some metric), make it bigger"
> and we need to define a middle ground if we want to avoid the
> appearence of moving goalposts.
>

Agreed, there are lots of mixed signals in this thread. For my uses the 'basic'
support being pushed won't be enough to use this in secure applications, nothing
less than full row-level access control would be.

I'm all for the community taking smaller patches over time but if there is no
intention of going all the way at the end then I'm not sure what you/we are gaining.