[refpolicy] Possible regression and bug in userdom_base_user_template

[dwalsh@redhat.com (Daniel J Walsh)]

On 02/24/2010 05:54 AM, 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.
>
> Regards,
> Michal Svoboda
>    
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>    
Allowing an application to execute usr_t, bin_t or any_t does not cause 
a transition.  You stay in your current domain.  So there is not a 
problem here.  You have the exact same access.  The goal of the policy 
in Fedora is to allow a confined user to execute random applications 
that we dont know about.  So if new binaries get installed in 
/usr/share/myapp/myapp.sh  We want the user to be able to execute it.   
But if xguest_t is not allowed to use the network myapp.sh is not going 
to allow the user to use the network.

We do not know where apps are going to be installed and making all users 
correct labeling is considered onerous and will just lead to people 
disabling SELinux or putting it into permissive mode.
Executing usr_t is not that big of a security risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100224/7d1622f3/attachment-0001.html