(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@xxxxxxxxxxxxx> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
