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

[KaiGai Kohei]

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.

Thanks,

(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,
> 
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-- 
KaiGai Kohei <kaigai at ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-dbadm-revise.3.patch
Type: text/x-patch
Size: 2409 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100816/cd4a84e8/attachment.bin