From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Wed, 24 Feb 2010 09:29:22 -0500 Subject: [refpolicy] Possible regression and bug in userdom_base_user_template In-Reply-To: <20100224105422.GC3990@myhost.felk.cvut.cz> References: <20100224105422.GC3990@myhost.felk.cvut.cz> Message-ID: <1267021762.9127.65.camel@gorn> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 2010-02-24 at 11:54 +0100, Michal Svoboda wrote: > Hi, > > I use a call like userdom_base_user_template(foo) to create foo_u, foo_r > and foo_t. On my debian installation with refpolicy 20080702, this > creates the following: > > sesearch --allow -s foo_t -p execute_no_trans > allow foo_t ld_so_t : file { ioctl read getattr execute execute_no_trans } ; > allow foo_t usr_t : file { ioctl read getattr lock execute execute_no_trans } ; > > Fast forward to today's refpolicy (or at least the one in fedora 12), > and you get > > allow foo_usertype application_exec_type : file { ioctl read getattr lock execute execute_no_trans open } ; > allow foo_usertype bin_t : file { ioctl read getattr lock execute execute_no_trans open } ; > allow foo_usertype chroot_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ; > allow foo_t usr_t : file { ioctl read getattr execute execute_no_trans open } ; > allow foo_usertype ld_so_t : file { ioctl read getattr execute execute_no_trans open } ; > allow foo_usertype shell_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ; > > So here go my questions: > 1) What's the story with the usr_t? The only executable files with that > label are possibly in /usr/games, and that one could have its own > usrgames_t or so. > 2) Why such an implosion of executable permissions? On the old system, > the new user can't execute almost anything, on the new system such an > identity equals free shell access. The Fedora list is more appropriate for this discussion, as these rules are specific to the Fedora policy. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150