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

[kaigai@kaigai.gr.jp (KaiGai Kohei)]

(2010/04/15 21:54), Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/15/2010 02:02 AM, 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?
>>
> I guess I would argue that the ability to mount a device can not be
> allowed to a confined administrator by default.   Since giving the
> ability to mount, allows the confined administrator and easy mechanism
> to break out of his confinement.
>
> mount -o bind mypasswd /etc/passwd  for example.
>
> I think mounting should be left to the sysadm_t/unconfined_t.  If the
> sysadm_t/unconfined_t wants to setup certain disks that can be mounted
> by the dbadm_t then he would either need to write a script and add
> policy for that script or write policy to allow the dbadm_t to
> transition to mount_t.

It seems to me fair enough. If confined administrators can mount disks
with their managing labels, it is equivalent to allow unconfined accesses.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>