(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(a)ak.jp.nec.com>