execmod avcs from today's policy

[Ivan Gyurdiev]

On Fri, 2005-01-28 at 13:55 -0500, Stephen Smalley wrote:
> On Fri, 2005-01-28 at 11:38, Tom London wrote:
> > Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc:  denied 
> > { execmod } for  pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2
> > ino=3178539 scontext=user_u:user_r:user_t
> > tcontext=system_u:object_r:shlib_t tclass=file
> 
> Naturally, relabeling libc to texrel_shlib_t isn't an option.
> Likewise for ld.so.  java needs to run in its own domain so that we only
> have to give execmod to shlib_t to specific domains, not the base user
> domain.  Care to make one?

What exactly is causing this denial... I see two more like it:

audit(1106919680.669:0): avc:  denied  { execmod } for  pid=26098
comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333
scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t
tclass=file

audit(1106919680.669:0): avc:  denied  { execmod } for  pid=26098
comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630
scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t
tclass=file

and

audit(1106936406.702:0): avc:  denied  { execmod } for  pid=669
comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333
scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t
tclass=file
audit(1106936406.798:0): avc:  denied  { execmod } for  pid=669
comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630
scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t
tclass=file

-- 
Ivan Gyurdiev <ivg2 at cornell.edu>
Cornell University