(2010/04/15 21:54), Daniel J Walsh wrote: > -----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. It seems to me fair enough. If confined administrators can mount disks with their managing labels, it is equivalent to allow unconfined accesses. Thanks, -- KaiGai Kohei <kaigai@xxxxxxxxxxxx> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
