From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 20 Apr 2009 16:07:24 -0400
Subject: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL
In-Reply-To: <49D965CA.4030908@ak.jp.nec.com>
References: <49D1DA85.1030902@ak.jp.nec.com>
	<49D4743C.2010000@ak.jp.nec.com>	<49D4CB6E.1090900@manicmethod.com>
	<1238684951.32379.311.camel@gorn.columbia.tresys.com>
	<49D563A9.1000607@ak.jp.nec.com>  <49D965CA.4030908@ak.jp.nec.com>
Message-ID: <1240258044.19211.767.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2009-04-06 at 11:15 +0900, KaiGai Kohei wrote:
> The attached patch provides some of reworks and bugfuxes
> except for new object classes and permissions.
> 
> - rework: Add a comment of "not currently in use" for deprecated
>   permissions, but its definitions are not removed.

"deprecated" should be sufficient.

> - bugfix: MCS policy did not constrain the following permissions.
>     db_database:{getattr}
>     db_table:{getattr lock}
>     db_column:{getattr}
>     db_procedure:{drop getattr setattr}
>     db_blob:{getattr import export}

Looks ok to me.

> - rework: All the newly created database objects by unprivileged
>   clients are prefixed with "user_", and these are controled via
>   sepgsql_enable_users_ddl.

I don't think we should be mixing user content with other unpriv
clients.

>   The current policy allows httpd_t to created a function labeled
>   as sepgsql_proc_t which is also allowed to be installed as a
>   system internal entity (db_procedure:{install}).
>   It is a potentially risk for trojan horse.
> 
> - rework: postgresql_role() shares most part of postgresql_unpriv_client().

See above comment.

> - bugfix: some of permissions in db_procedure class are allowed
>   on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
>   It should allow them on sepgsql_trusted_proc_exec_t.
>   I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
>   such kind of confusion, as Chris suggested before.
> 
> - rework: we should not allow db_procedure:{install} on the
>   sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
>   procedure implicitly.
> 
> - rework: db_table:{lock} is moved to reader side, because it makes
>   impossible to refer read-only table with foreign-key constraint.
>   (FK checks internally acquire explicit locks.)
> 
> - bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
>   but it is required whrn the largeobject is refered.
> 
> - bugfix: MLS policy didn't constrain the db_procedure class.

Seems ok.

It would be helpful to break up the patch into a set to make it easier
to review in the future.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150