Re: 8.4 release planning

Tom Lane wrote:
> Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
>> It seems to me that there are two different standards to which this feature
>> might be held.
>
>> Is the goal
>> a) SEPostgres can provide useful rules to add security to some
>> specific applications so long as you're careful to avoid crafting
>> policies that produce bizarre behaviors (like avoiding restricing
>> access to foreign key data you might need). On the other hand it
>> gives you enough rope to hang yourself and produce weird results
>> that don't make sense from a SQL standard point of view if you
>> aren't careful matching the SEPostgres rules with your apps.
>
>> or
>> b) SEPostgreSQL should only give enough rope that you can not
>> craft rules that produce unexpected behavior from a SQL point
>> of view; and that it would be bad if one can produce SEPostgres
>> policies that produce unexpected SQL behavior.
>
> With my other hat on (the red one) what I'm concerned about is whether
> this patch will ever produce a feature that I could turn on in the
> standard Red Hat/Fedora build of Postgres. Right at the moment it seems
> that the potential performance hit, for users who are *not using*
> SEPostgres but merely have to use a build in which it is present,
> might be bad enough to guarantee that that will never happen.
>

According to the comments in security/sepgsql/core.c:

/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsqlXXXX() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option "sepostgresql" can have the following four parameter.
*
* - default : It always follows the in-kernel SELinux state. When it
* works in Enforcing mode, SE-PostgreSQL also works in
* Enforcing mode. Changes of in-kernel state are delivered
* to userspace SE-PostgreSQL soon, and SELinux state
* monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
* has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
* has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
* original PostgreSQL
*/

and in the hooks there is a pgace_feature that turns off the checks:

void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}

if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg("unable to set security attribute of
table "
"via ALTER TABLE")));
}

So the pgace_feature turns off the backend call, there is an extra function
call, and a branch but that shouldn't cause the kind of performance degradation
you are talking about.