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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
