execmod avcs from today's policy

[Tom London]

On Fri, 28 Jan 2005 20:06:21 -0700, Ivan Gyurdiev <ivg2 at cornell.edu> wrote:
> 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
> 
Here's my understanding:

The new kernel/policy can now enforce controls on the modification to
memory mapped regions that can be executed.  I think this is a very
good thing.....

However, existing code/applications do funny things with such memory
mapped regions (like writing one word, like relocating, like ....), so
we get these AVCs for them.

There seem to be two approaches to fix: first, fix the apps (I believe
you need new tool chain at least, or am I getting confused....), and
now that there policy support, create policy specs for the apps that
need it.

In my case, I see these for the Sun Jave JVM I have installed. In your
case, looks like 'setiathome' and 'ut2004' are the culprits.

Do I have this correct?
   tom
-- 
Tom London