From: kaigai@ak.jp.nec.com (KaiGai Kohei) Date: Wed, 18 Aug 2010 17:19:06 +0900 Subject: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package) In-Reply-To: <4C6ACE52.60905@gentoo.org> 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> <4C6994B4.5050905@tresys.com> <4C69CBC9.4090904@ak.jp.nec.com> <4C6ACE52.60905@gentoo.org> Message-ID: <4C6B977A.4040402@ak.jp.nec.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com (2010/08/18 3:00), Chris PeBenito wrote: > On 08/16/10 19:37, KaiGai Kohei wrote: >> (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. > > My mistake, I misread it. You're right, its fine. > >>> 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? > > Based on what I see in the policy, my guess is this file is created by > the init script, right? If not, then it sounds like PostgreSQL needs a > lock type. > Yes, this file is created by the init script. In addition, postgresql_lock_t is defined, but type_transition rule is defined on a pair of postgresql_t and var_lock_t, so the lockfile shall be labeled as var_lock_t. [root at saba ~]# ls -Z /var/lock/subsys/postgresql -rw-r--r--. root root dbadm_u:object_r:var_lock_t:s0 /var/lock/subsys/postgresql Maybe, init script should relabel it to postgresql_lock_t, ideally? > I'd rather it just have delete permissions, rather than full manage > permissions. Something like files_delete_all_locks(), but for var_lock_t > instead. > I tried to define files_delete_generic_locks(), instead of the manage. Thanks, -- KaiGai Kohei -------------- next part -------------- A non-text attachment was scrubbed... Name: refpolicy-dbadm-revise.4.patch Type: text/x-patch Size: 3441 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100818/1de3086e/attachment.bin