-----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.
Thanks,
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux