Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)

On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users
>> to invoke functions installed by other malicious/untrusted one, typically
>> known as trojan-horse.
>> ...
>> We should not assume only C-functions can be installed on pg_conversion
>> (and other internal stuff), because a superuser can update system catalog
>> by hand.
>> ...
>> SE-PostgreSQL intends to acquire them and apply access control policy
>> in this case also.
>
> I don't think that anyone except KaiGai-san has bought into the concept
> that sepostgres should get to override superuser capabilities, much less
> that it should be trying to control semantics at this kind of level of
> detail.

I'd find that VERY surprising. One of the major features of MAC
systems is that the system policy trumps decisions by individual
users, so root or the database superuser is confined by that policy
just like everyone else. They may or may not have the ability to
change the policy, but that's a separate issue.

> I've been convinced for awhile that the sepostgres project is going
> off the rails, and these last couple of exchanges just confirm the fear.

I'm not sure what you mean by "going off the rails". I think we are
still beating our way through what Peter Eisentraut said in one of his
first reviews of this patch: SE-PostgreSQL shouldn't implement MAC
that isn't a mirror of existing DAC capabilities. If more
capabilities are needed, the DAC side of things should be designed and
implemented first. Interestingly, Heikki's latest review comments are
coming back to exactly this point. So I think we have unanimity that
everything that doesn't meet this criterion should be ripped out for
now. But I don't see anyone arguing that those capabilities are
intrinsically worthless, except possibly you, just that we won't be
ready to support them in SE-PostgreSQL until we support them in some
more general sense.

> This is absolutely *not* the kind of thing that we should be designing
> four months after feature freeze.

On this point I am in agreement. We need very much to bring this
"November" CommitFest to an end. Unfortunately, the pace of reviewing
slowed dramatically after Thanksgiving and has since dropped to a
crawl. However, since the decision to bump Hot Standby was made,
things have picked up again, mostly due to a bunch of reviewing by
Heikki. The thing we need to do now is make that reviewing reach some
conclusion about exactly what needs to be fixed and what of it will be
fixed by the author vs. by the committer. It would be easier to make
the decision to bump SE-PostgreSQL if it were the only thing holding
up beta, but we're not there yet.

...Robert