strict policy problem

[Stephen Smalley]

On Mon, 2005-10-03 at 23:16 -0400, Richard Hally wrote:
> Perhaps someone who understands the problem and possibly the solution 
> and which package to file against could help us out here?

I'd file it against firefox, as that owns the .so files that are
triggering these denials.  Someone needs to look at the build process
and code for those .so files to determine why they presently require
text relocations and how to fix them.  

> Just speculating here but it seems that something is being kept in 
> memory from relabeling that allows these apps to start but is not there 
> when doing an ordinary boot. But that is just speculation. Is it FF and 
> T'bird or is it SELinux?

Hmm...well, SELinux should trigger an execmod denial on shlib_t always,
regardless of the MCS level.  Labeling them with texrel_shlib_t should
make it go away, but it would be better to fix the files to not require
text relocations.

It is possible for the incore inode security label to become
inconsistent with the on-disk xattr (example: access a file with a given
type to bring its inode incore and map its xattr to an incore label,
then remove the type from the policy and reload it, at which point the
incore label will be remapped to the unlabeled_t type, and remain that
way until the inode is evicted from memory even if a subsequent policy
reload re-adds the type).  The patch queued up for 2.6.15 that will
allow SELinux to canonicalize getxattr results will ensure that a
getxattr/getfilecon will always return the actual incore inode security
label to userspace.

-- 
Stephen Smalley
National Security Agency