strict policy problem

[Richard Hally]

would someone please fix the problem with firefox and thunderbird not 
starting when using the latest strict 
policy(selinux-policy-strict-1.27.1-11)?  Below are the AVC messages 
from audit.log when trying to start them
Thanks,
Richard Hally

type=AVC msg=audit(1128231114.093:32): avc:  denied  { execmod } for  
pid=2731 comm="firefox-bin" name="libxpcom_core.so" dev=dm-0
ino=3965047 
scontext=richard:staff_r:staff_mozilla_t:s0-s0:c0.c127 
tcontext=system_u:object_r:shlib_t:s0 tclass=file
type=SYSCALL msg=audit(1128231114.093:32): arch=40000003 syscall=125 
success=no exit=-13 a0=e9c000 a1=e0000 a2=5 a3=bfd2a710 items=0 pid=2731 
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 
sgid=500 fsgid=500 comm="firefox-bin"
exe="/usr/lib/firefox-1.5/firefox-bin"
type=AVC_PATH msg=audit(1128231114.093:32):  
path="/usr/lib/firefox-1.5/libxpcom_core.so"
-----------------------------------------------------------
type=AVC msg=audit(1128231322.472:40): avc:  denied  { execmod } for  
pid=2869 comm="thunderbird-bin" name="libxpcom_core.so" dev=dm-0 
ino=3701297 scontext=richard:staff_r:staff_thunderbird_t:s0-s0:c0.c127 
tcontext=system_u:object_r:shlib_t:s0 tclass=file
type=SYSCALL msg=audit(1128231322.472:40): arch=40000003 syscall=125 
success=no exit=-13 a0=739000 a1=e0000 a2=5 a3=bfe1ebc0 items=0 pid=2869 
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 
sgid=500 fsgid=500 comm="thunderbird-bin" 
exe="/usr/lib/thunderbird-1.5/thunderbird-bin"
type=AVC_PATH msg=audit(1128231322.472:40):  
path="/usr/lib/thunderbird-1.5/libxpcom_core.so"

[Ivan Gyurdiev]

Richard Hally wrote:
>  would someone please fix the problem with firefox and thunderbird not
>
>  starting when using the latest strict 
>  policy(selinux-policy-strict-1.27.1-11)?  Below are the AVC messages 
>  from audit.log when trying to start them
>  
Hi Richard, the problem is easily worked around by marking the following 
libraries texrel_shlib_t, as they contain Text Relocations. However, I 
think a better goal would be to eliminate those text relocations where 
possible, along with the rest of the libraries marked in distros.fc.

Steven, can you clarify what needs to be done to get fix those 
applications...
I am currently not very clear on what the problem is, since I'm not 
familiar with the linking process.

/usr/lib/firefox-1.5/libgfxpsshar.so
/usr/lib/firefox-1.5/libgkgfx.so
/usr/lib/firefox-1.5/libxpcom_compat.so
/usr/lib/firefox-1.5/libgtkembedmoz.so
/usr/lib/firefox-1.5/libxpcom_core.so
/usr/lib/firefox-1.5/libgtkxtbin.so
/usr/lib/firefox-1.5/libxpcom.so
/usr/lib/firefox-1.5/libjsj.so
/usr/lib/firefox-1.5/libsoftokn3.so
/usr/lib/firefox-1.5/libxpistub.so

[Stephen Smalley]

On Sun, 2005-10-02 at 03:19 -0400, Ivan Gyurdiev wrote:
>  Hi Richard, the problem is easily worked around by marking the
> following 
>  libraries texrel_shlib_t, as they contain Text Relocations. However, I 
>  think a better goal would be to eliminate those text relocations where 
>  possible, along with the rest of the libraries marked in distros.fc.
>  
>  Steven, can you clarify what needs to be done to get fix those 
>  applications...
>  I am currently not very clear on what the problem is, since I'm not 
>  familiar with the linking process.
>  
>  /usr/lib/firefox-1.5/libgfxpsshar.so
>  /usr/lib/firefox-1.5/libgkgfx.so
>  /usr/lib/firefox-1.5/libxpcom_compat.so
>  /usr/lib/firefox-1.5/libgtkembedmoz.so
>  /usr/lib/firefox-1.5/libxpcom_core.so
>  /usr/lib/firefox-1.5/libgtkxtbin.so
>  /usr/lib/firefox-1.5/libxpcom.so
>  /usr/lib/firefox-1.5/libjsj.so
>  /usr/lib/firefox-1.5/libsoftokn3.so
>  /usr/lib/firefox-1.5/libxpistub.so 
I think that one would have to go look at the actual code and build
process for those objects to determine why they are being marked as
requiring textrel and what needs to be done to fix them.  Were they
built with -fpic?  Do they include hand-written assembly?  Ulrich, is
there a FAQ anywhere already to which we can refer people to help them
track down the cause of text relocations and fix them (not just working
around them in policy)?

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote:
>  would someone please fix the problem with firefox and thunderbird not
>
>  starting when using the latest strict 
>  policy(selinux-policy-strict-1.27.1-11)?  Below are the AVC messages 
>  from audit.log when trying to start them 
You should always bugzilla such issues so that they can be tracked
properly...

-- 
Stephen Smalley
National Security Agency

[Richard Hally]

Stephen Smalley wrote:
>  On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote:
>  
> >would someone please fix the problem with firefox and thunderbird not 
> >starting when using the latest strict 
> >policy(selinux-policy-strict-1.27.1-11)?  Below are the AVC messages 
> >from audit.log when trying to start them
>  
>  
>  You should always bugzilla such issues so that they can be tracked
>  properly...
>   
Perhaps someone who understands the problem and possibly the solution 
and which package to file against could help us out here?

BTW, the other part of the problem is possibly related to the "devel's 
mcs breaks prelink and FC4 compat" thread.
When I do 'touch /.autorelabel' and reboot, Firefox and Thunderbird will 
start. If I then do another reboot without the autorelabel they will 
then not start.

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?

Also, this problem has been occurring with Firefox for several months 
but has only started occurring with T'bird in the last week or so. These 
are the only two apps I have tried on my strict/MCS test box.

Richard Hally

[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

[Richard Hally]

Stephen Smalley wrote:
>  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.  
>   
Perhaps it would be appropriate to reevaluate the implementation
strategy for this particular "feature" of SELinux.

If there is no coherent, concise, convincing explanation provided to the 
people who need to make changes to their software to conform to the 
requirements of this "feature" then there isn't much hope of them doing 
what is required. Since this "feature" was implemented many months ago 
and these problems are still appearing please consider filing bugs with 
the appropriate explanation so that the appropriate people can make the 
required changes.

Thanks,
Richard Hally

[Stephen Smalley]

On Tue, 2005-10-04 at 17:04 -0400, Richard Hally wrote:
>  Perhaps it would be appropriate to reevaluate the implementation
>  strategy for this particular "feature" of SELinux.
>  
>  If there is no coherent, concise, convincing explanation provided to the 
>  people who need to make changes to their software to conform to the 
>  requirements of this "feature" then there isn't much hope of them doing 
>  what is required. Since this "feature" was implemented many months ago 
>  and these problems are still appearing please consider filing bugs with 
>  the appropriate explanation so that the appropriate people can make the 
>  required changes. 
Hi,

I think all you need to do is file a bugzilla against firefox and report
what you reported originally, and note that these .so's have text
relocations.  Then it is up to the maintainer for that package (and
ultimately the upstream developers) to address the issue.  The notion
that text relocations are bad isn't something novel to SELinux by any
means.  We simply added controls to SELinux over the resulting attempt
to modify the memory protections at the suggestion of the Red Hat
developers so that this can be controlled by policy.

You can also bugzilla policy if you like so that the permissions can be
added in the short term until the package is fixed.

This is no different than any other bug you might encounter in a
particular package; when you find the bug, file it against the package.
The policy can certainly workaround it in the short term, but that
doesn't improve security; it just permits the status quo.
  
-- 
Stephen Smalley
National Security Agency