From: michal.svoboda@agents.felk.cvut.cz (Michal Svoboda)
Date: Wed, 24 Feb 2010 11:54:22 +0100
Subject: [refpolicy] Possible regression and bug in
	userdom_base_user_template
Message-ID: <20100224105422.GC3990@myhost.felk.cvut.cz>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

Regards,
Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100224/bb69f532/attachment-0001.bin