From: dwalsh@redhat.com (Daniel J Walsh) Date: Thu, 15 Apr 2010 08:54:03 -0400 Subject: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package) In-Reply-To: <4BC6ABDE.6040005@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> Message-ID: <4BC70C6B.6090702@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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 at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvHDGsACgkQrlYvE4MpobP4TwCcCUBCw8yaoLAuSkmLtfQlytgh wxMAoKCfnHr+/BwUX0ep+XzblvYn/jjn =+Cf6 -----END PGP SIGNATURE-----