From: kaigai@ak.jp.nec.com (KaiGai Kohei)
Date: Fri, 08 May 2009 13:05:07 +0900
Subject: [refpolicy] [RFC] Security policy reworks for SE-PostgreSQL
In-Reply-To: <4A03AD55.8020207@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>		<1240258044.19211.767.camel@gorn.columbia.tresys.com>		<49ED04DF.8050306@ak.jp.nec.com>	<1241699079.19211.1251.camel@gorn.columbia.tresys.com>
	<4A03AD55.8020207@ak.jp.nec.com>
Message-ID: <4A03AF73.4040407@ak.jp.nec.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.

The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.

In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.

The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.

Thanks,

KaiGai Kohei wrote:
>>>>> - 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.
>>> I would like to discriminate between a procedure declared by unpriv
>>> client and by administrative client, because the policy allows the
>>> unprefixed "sepgsql_proc_exec_t" to be installed as a system internal
>>> component, but it is undesirable to install unpriv-user defined
>>> procedures as is.
>>>
>>> If the "user_" prefix is unpreferable, how do you think other prefixes
>>> something like "anon_", "unpriv_" and so on?
>> I think we should go with unpriv_ for now.
> 
> OK, the attached patch adds the following types for unprivileged clients.
>  - unpriv_sepgsql_table_t
>  - unpriv_sepgsql_sysobj_t
>  - unpriv_sepgsql_proc_exec_t
>  - unpriv_sepgsql_blob_t
> 
> These types are the default for unprivileged and unprefixed domains,
> such as httpd_t and others.
> 
> In addition, TYPE_TRANSITION rules are moved to outside of tunable
> of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
> tunable because UBAC domains (user_t and so on) were allowed to
> create sepgsql_table_t, and its default was pointed to this type
> when sepgsql_enable_users_ddl is disabled.
> However, it has different meanings now, so the TYPE_TRANSITION rules
> should be unconditional.
> 
> Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-2-correct-sepgsql_enable_users_ddl.patch
Type: text/x-patch
Size: 3331 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090508/440c820d/attachment.bin