From: michal.svoboda@agents.felk.cvut.cz (Michal Svoboda)
Date: Mon, 1 Mar 2010 18:03:24 +0100
Subject: [refpolicy] Possible regression and bug in
 userdom_base_user_template
In-Reply-To: <1267457544.30557.30.camel@gorn.columbia.tresys.com>
References: <20100301102220.GF3990@myhost.felk.cvut.cz>
	<1267450925.30557.7.camel@gorn.columbia.tresys.com>
	<20100301150133.GG3990@myhost.felk.cvut.cz>
	<1267457544.30557.30.camel@gorn.columbia.tresys.com>
Message-ID: <20100301170324.GI3990@myhost.felk.cvut.cz>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Christopher J. PeBenito wrote:
> I don't know what you are referring to; I don't see such access in
> refpolicy.  I can see that the base user template can read usr_t files,
> but not execute them.  I even added a test user that only called the
> template and opened up the compiled policy with apol; it still did not
> have an execute permission on usr_t.

This is weird.

# cat foo.te
policy_module(foo,1.0.0)

userdom_base_user_template(foo)

# sesearch --allow -s foo_t -p execute_no_trans
Found 2 semantic av rules:
   allow foo_t usr_t : file { ioctl read getattr lock execute
   				execute_no_trans open } ;
   allow foo_t ld_so_t : file { read getattr execute execute_no_trans open } ;

# aptitude show selinux-policy-default |grep -i vers
Version: 2:0.2.20091117-1

Either the policy changed since then or this is a debian only patch...

> There is no template that restrictive.  In fact, its impossible to
> accomplish that unless you have statically-linked programs, since
> dynamic linking requires execute on shared libraries.

I know, that's the ld_so_t, but on that one you could semi-count that
it's not used outside its ideal world scope.

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/20100301/7c751a31/attachment.bin