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

[KaiGai Kohei]

(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:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> 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?

> Use of staff_role_change_to() is not allowed upstream.  If staff should
> be allowed to change to dbadm, the dbadm_role_change() should be used in
> the staff module.

OK, I'll fix it.

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