execmod avcs from today's policy

[Stephen Smalley]

On Fri, 2005-01-28 at 22:06, Ivan Gyurdiev 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

Legacy binaries (those that lack PT_GNU_STACK on x86) have PROT_READ
mmap/mprotect requests automatically translated to PROT_READ|PROT_EXEC
for backward compatibility.  The dynamic linker needs to modify one word
in the mapping, so the linker makes it writable, modifies the word, and
changes it back to read-only.  But since it is a legacy binary, the
kernel views the latter as an attempt to make executable a mapping that
was previously modified, and triggers the execmod permission check on
it.  Such legacy binaries should be placed into a separate domain so
that they can be separately confined.

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