Re: How to get SE-PostgreSQL acceptable

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to get SE-PostgreSQL acceptable
Date: 2009-01-29 03:08:57
Message-ID: 20090129030857.GD8123@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> I agree that that's no good.

As do I.

> My concern is that superuser is allowed to modify system catalog
> by hand, like:
>
> UPDATE pg_proc SET probin = '/tmp/malicious_library.so'
> WHERE oid = ...;

That UPDATE still goes through permissions checking, and that checking
even includes an explicit check when system catalogs are involved.
Appropriate hooks in that permission checking could prevent this from
ever being allowed.

> It is logically same as ALTER FUNCTION.

Sure, but I think it's straight-forward to make a case for "don't update
the system catalogs when you're running SE-PostgreSQL, use the
appropriate ALTER commands", and then remove the ability to do so when
SE-PostgreSQL is enabled.

>> Can you (or someone) provide a pointer to the archives? I can't
>> immediately see any reason why that problem wouldn't be fixable.
>
> IIRC, 0racle or M$ has a patent to rewrite WHERE clause for security
> purpose, so Tom suggested it should be implemented using a hook
> deployed within executor.
> At least, it also enables code more simple.

It'd probably be Oracle.. I'm not a big fan of that approach anyway
though, although I don't have any particular reason beyond 'it feels
kludgy' at the moment.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-01-29 03:12:10 Re: pg_upgrade project status
Previous Message KaiGai Kohei 2009-01-29 02:49:06 Re: How to get SE-PostgreSQL acceptable