execmod avcs from today's policy

[Stephen Smalley]

On Sat, 2005-01-29 at 11:56, Tom London wrote:
> 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.....

execmem permission controls the ability to make executable an anonymous
mapping or a writable private file mapping.  execmod permission controls
the ability to make executable a previously modified private file
mapping.  The controls were introduced in
http://marc.theaimsgroup.com/?l=bk-commits-head&m=110491550432114&w=2.

> 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.

The dynamic linker needs to write one word; normally, this isn't a
problem as the mapping in question is not executable.  However, for
legacy binaries, the read protection is translated to read|execute,
which then triggers the checks.  

> 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.

Newer tool chain will at least try to classify the application and mark
it accordingly.  Modifications to the application or its build may be
necessary to avoid unnecessarily lax marking.

> 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?

Yes.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency