From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 19 Aug 2010 08:47:41 -0400
Subject: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not
 available in selinux-policy package)
In-Reply-To: <4C6B977A.4040402@ak.jp.nec.com>
References: <4BBD28D0.8080204@ak.jp.nec.com>		<20100408082729.GE25042@localhost.localdomain>		<4BBDC8E5.1050307@redhat.com>	<4BBEBB52.9090907@ak.jp.nec.com>		<1271081355.2815.191.camel@gorn.columbia.tresys.com>		<4BC3BAA5.4050502@ak.jp.nec.com>		<1271164663.2815.214.camel@gorn.columbia.tresys.com>		<4BC48A80.3000808@redhat.com>	<1271174238.2815.222.camel@gorn.columbia.tresys.com>	<4BC6ABDE.6040005@ak.jp.nec.com>	<4C6900CD.7070600@ak.jp.nec.com>
	<4C6994B4.5050905@tresys.com> <4C69CBC9.4090904@ak.jp.nec.com>
	<4C6ACE52.60905@gentoo.org> <4C6B977A.4040402@ak.jp.nec.com>
Message-ID: <4C6D27ED.5060109@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/18/10 04:19, KaiGai Kohei wrote:
> (2010/08/18 3:00), Chris PeBenito wrote:
>> On 08/16/10 19:37, KaiGai Kohei wrote:
>>> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>>>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>>>> Sorry for this long silent on the topic.
>>>>>
>>>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>>>
>>>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>>>> so, userdom_base_user_template() is used to grant basic privileges
>>>>> to dbadm_t instead of userdom_unpriv_user_template().
>>>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>>>
>>>>> Did we have any more issues?
>>>>>
>>>>> The attached patch is same as the last version except for it was
>>>>> rebased
>>>>> to the latest reference policy.
>>>>
>>>> I only have two issues:
>>>>
>>>> 1. Why should dbadm be allowed to set enforce mode?
>>>
>>> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
>>> We just allow dbadm_t to see the current working mode.
>>
>> My mistake, I misread it. You're right, its fine.
>>
>>>> 2. Why does dbadm need to manage generic locks?
>>>
>>> It was originally copied from webadb.te, but PostgreSQL also makes
>>> its lockfile on the /var/lock/subsys/postgresql. If server process
>>> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
>>
>> Based on what I see in the policy, my guess is this file is created by
>> the init script, right? If not, then it sounds like PostgreSQL needs a
>> lock type.
>>
> Yes, this file is created by the init script.
>
> In addition, postgresql_lock_t is defined, but type_transition rule is
> defined on a pair of postgresql_t and var_lock_t, so the lockfile shall
> be labeled as var_lock_t.
>
>    [root at saba ~]# ls -Z /var/lock/subsys/postgresql
>    -rw-r--r--. root root dbadm_u:object_r:var_lock_t:s0   /var/lock/subsys/postgresql
>
> Maybe, init script should relabel it to postgresql_lock_t, ideally?

It might be nice to do this for all services, but since it requires 
script changes, its not likely to happen.  So theres probably no point 
in doing this for just a couple services.

As it is, I think its more of a lock for the init script system, so if 
anything we should probably think about making these locks made by the 
init scripts have a initrc_lock_t type.

>> I'd rather it just have delete permissions, rather than full manage
>> permissions. Something like files_delete_all_locks(), but for var_lock_t
>> instead.
>>
> I tried to define files_delete_generic_locks(), instead of the manage.

Merged, with one minor change -- I moved the declaration of the above 
interface.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com