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