From: kaigai@ak.jp.nec.com (KaiGai Kohei)
Date: Fri, 27 Mar 2009 17:18:55 +0900
Subject: [refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas
 in SE-PostgreSQL enhancement)
In-Reply-To: <49C9D524.9050208@ak.jp.nec.com>
References: <49C7667A.3020804@ak.jp.nec.com> <49C7A88E.4020408@rubix.com>
	<49C84200.9090107@ak.jp.nec.com> <49C9D524.9050208@ak.jp.nec.com>
Message-ID: <49CC8BEF.507@ak.jp.nec.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

The attached patch is the first one in the series of reworks for
the SE-PostgreSQL security policy.

It updates the following items.

* Changes in the definition of object classes

This patch add new three object classes and modifies the definition
of a few object classes.
 - db_database:{get_param set_param} is removed due to nonsense.
 - db_database:{superuser} is added to restrict privileges of
   database superuser.
 - db_table/db_column/db_tuple:{use} is removed due to nonsense.
 - New object classes: db_catalog, db_schema and db_sequence are added.

In the previous design, we have the following object hierarchy:
  [db_database]
   + [db_table]
   |  + [db_column]
   |  + [db_tuple]
   + [db_procedure]
   + [db_blob]

The newly added db_schema should be placed between the db_database and
the db_table and others. TYPE_TRANSITION rules follows the revised design.

  [db_database]
   + [db_schema]
   |  + [db_table]
   |  |   + [db_column]
   |  |   + [db_tuple]
   |  + [db_procedure]
   |  + [db_sequence] (newly added object class)
   + [db_blob]

  (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
      although it can be used to communicate channel between multiple
      domains. So, it needs to be placed under the database.

Currently, SE-PostgreSQL does not use db_catalog class, but it can be
used for other DBMS's.

In addition, this patch changes something.

 o The trusted procedure (sepgsql_trusted_proc_t) lost the
   db_database:{superuser} privilege, because it is invoked by
   unprived users to over the MAC restriction for a certain
   purpose, but it does not need to allow superpower in DAC.

 o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
   db_procedure:{install} privilege, because once installed procedure
   as a system internal entity can be invoked implicitly.
   We should not install trusted procedures for the purpose.

 o The db_schema:{add_object remove_object} newly added are controled
   via the "sepgsql_enable_users_ddl" boolean.
   Now we control user's DDLs on uncategorized objects as row-level
   checks on sepgsql_sysobj_t, but it can be revised with adding
   db_schema object class.

 o type_transition for user_sepgsql_XXXX_t is moved to outside of
   tunable_policy(`...'). IIRC, I said these should be inside of
   the tunable, but unprive ones cannot create/drop tables labeled
   as sepgsql_XXX_t anyway when the boolean is disabled.
   So, I reconsidered it should be placed out of the tunable.

 o {create drop setattr} permission for user_sepgsql_XXX is moved
   to inside of the tunable_policy, even if it is db_procedure
   class. I wonder why we didn't control CREATE FUNCTION statement
   by unpriv domains.

 o db_blob:{import export} on user_sepgsql_blob_t is allowed to
   unpriv domains. It seems to me a strange behavior that it is
   not allowed on the object created by unpriv domain itself.

* Remaining items
 o When we allows an unpriv domain to access SE-PostgreSQL using
   postgresql_unpriv_client(), its default labeling behavior is
   same as unconfined domains. For example, functions created by
   them are labeled as "sepgsql_proc_t".
   Now I'm considering it should be user_sepgsql_XXXX_t, because
   I would like to handle unprefixed types as an object created
   by database administrator (unconfined domains).
   It helps correctness of db_procedure:{install} permission.

 o Because of db_schema object class, we can control user's DDLs
   without ad-hoc using row-level security on sepgsql_sysobj_t
   class. Now I think its purpose should be changed to prevent
   users accesses system catalogs directly.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-rework.1.patch
Type: text/x-patch
Size: 17303 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090327/133fa094/attachment.bin