[refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)

[KaiGai Kohei]

(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.

> 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?

Thanks,

> After those are resolved, it can be merged.
> 
>> (2010/04/15 15:02), KaiGai Kohei wrote:
>>> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>>>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>>>> As Dominick stated. I prefer to think in terms of two 
>>>>>>>>>> different roles.
>>>>>>>>>> Login Roles, and Roles to execute in when you have privileges 
>>>>>>>>>> (IE Root).
>>>>>>>>>>
>>>>>>>>>> Login Roles/Types
>>>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>>>
>>>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>>>
>>>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Admin Roles/Types
>>>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>>>
>>>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin 
>>>>>>>>>> Role.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I imagine that you login as a confined user and then use 
>>>>>>>>>> sudo/newrole to
>>>>>>>>>> switch roles to one of the admin roles.
>>>>>>>>>
>>>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the 
>>>>>>>>> upstream
>>>>>>>>> reference policy). It uses userdom_base_user_template() instead 
>>>>>>>>> of the
>>>>>>>>> userdom_unpriv_user_template(), and should be launched via 
>>>>>>>>> sudo/newrole.
>>>>>>>>> In the default, it intends the dbadm_r role to be launched by 
>>>>>>>>> staff_r role.
>>>>>>>>
>>>>>>>> Why does dbadm need to run setfiles?
>>>>>>>
>>>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be 
>>>>>>> labeled
>>>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>>>> However, as long as they initialize database files using init 
>>>>>>> script,
>>>>>>> initrc_t domain performs this initial labeling, so it might not 
>>>>>>> be necessary.
>>>>>>>
>>>>>>> On the other hand, PostgreSQL support a feature to use multiple 
>>>>>>> disks
>>>>>>> within a single database instance for performance utilization.
>>>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>>>
>>>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>>>
>>>>>>> It requires administrators to assign proper security context on 
>>>>>>> the secondary
>>>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>>>
>>>>>>> Is there any good idea?
>>>>>>>
>>>>>>> Or, it should not be a task for dbadm?
>>>>>>
>>>>>> Ok, the transition for setfiles is fine.
>>>>>>
>>>>>
>>>>> I would be carefull with this. Since setfiles can take a parameter 
>>>>> of a
>>>>> file context file. I think it would be better to only give
>>>>> relabefrom/relabelto privs for all labels dbadm_t can manage. Then
>>>>> figure out what access is required to mount.
>>>>
>>>> Good point. We should probably reconsider the setfiles usage from
>>>> webadm too.
>>>
>>> The attached patch is a revised one.
>>> - seutil_domtrans_setfiles() was removed
>>> - staff_role_change_to() was removed, and I put dbadm_role_change()
>>> on the staff.te
>>> - Fix an obvious typo.
>>>
>>> It is not clear for me whether the idea to allow relabelfrom/relabelto
>>> for all the files dbadm_t can manage, because it is eventually necessary
>>> someone to relabel (or assign initial labels) files from unlabeled one
>>> to managed labels when we mount a new disk.
>>>
>>> If so, should it be a task of sysadm_t to mount new disk and assign
>>> security context correctly, instead of webadm_t/dbadm_t?
>>>
>>> Thanks,
> 


-- 
KaiGai Kohei <kaigai at ak.jp.nec.com>