From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 16 Aug 2010 15:42:44 -0400 Subject: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package) In-Reply-To: <4C6900CD.7070600@ak.jp.nec.com> References: <4BBD28D0.8080204@ak.jp.nec.com> <20100408082729.GE25042@localhost.localdomain> <4BBDC8E5.1050307@redhat.com> <4BBEBB52.9090907@ak.jp.nec.com> <1271081355.2815.191.camel@gorn.columbia.tresys.com> <4BC3BAA5.4050502@ak.jp.nec.com> <1271164663.2815.214.camel@gorn.columbia.tresys.com> <4BC48A80.3000808@redhat.com> <1271174238.2815.222.camel@gorn.columbia.tresys.com> <4BC6ABDE.6040005@ak.jp.nec.com> <4C6900CD.7070600@ak.jp.nec.com> Message-ID: <4C6994B4.5050905@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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? 2. Why does dbadm need to manage generic locks? 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, -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com