kernel-2.6.10-1.1074_FC4 breaks firefox?

[Tom London]

Running strict/enforcing, latest Rawhide.

After downloading today's updates, including
kernel-2.6.10-1.1074_FC4, and rebooting,
(and before the kernel oops with a kernel
page fault):

firefox refuses to start in enforcing mode. Here
are the AVCs:

Jan  8 10:28:01 fedora kernel: audit(1105208881.086:0): avc:  denied 
{ execmod } for  pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2
ino=3178514 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:ld_so_t tclass=file
Jan  8 10:28:01 fedora kernel: audit(1105208881.831:0): avc:  denied 
{ execmem } for  pid=4266 comm=firefox-bin
scontext=user_u:user_r:user_mozilla_t
tcontext=user_u:user_r:user_mozilla_t tclass=process
Jan  8 10:28:01 fedora kernel: audit(1105208881.928:0): avc:  denied 
{ execmem } for  pid=4266 comm=firefox-bin
scontext=user_u:user_r:user_mozilla_t
tcontext=user_u:user_r:user_mozilla_t tclass=process

Policy needs fixing for new kernel mods?

tom
-- 
Tom London

[Tom London]

Same problem in 1075_FC4.

Works (with similar AVCs) in permissive mode.

tom

[Tom London]

Uhhh....This went away on this mornings boot.....

I don't remember changing anything to fix it.....

Could a cron  triggered job have fixed this...?

tom

[Tom London]

Sorry, accidently booted 1063_FC4 by accident.

Still happens in 1075_FC4.

tom

-- 
Tom London

[Tom London]

OK. My fault....

This is caused by the Sun java plugin and by the Adobe
pdf plugin.

Removing them allows firefox to startup and work.

Still get these AVCs:

Jan 10 21:39:31 fedora kernel: audit(1105421971.189:0): avc:  denied 
{ execmem } for  pid=6696 comm=firefox-bin
scontext=user_u:user_r:user_mozilla_t
tcontext=user_u:user_r:user_mozilla_t tclass=process
Jan 10 21:39:33 fedora kernel: audit(1105421973.479:0): avc:  denied 
{ execmem } for  pid=6696 comm=firefox-bin
scontext=user_u:user_r:user_mozilla_t
tcontext=user_u:user_r:user_mozilla_t tclass=process
Jan 10 21:39:33 fedora kernel: audit(1105421973.487:0): avc:  denied 
{ execmem } for  pid=6696 comm=firefox-bin
scontext=user_u:user_r:user_mozilla_t
tcontext=user_u:user_r:user_mozilla_t tclass=process

tom
-- 
Tom London

[Stephen Smalley]

On Sat, 2005-01-08 at 13:41, Tom London wrote:
>  Running strict/enforcing, latest Rawhide.
>  
>  After downloading today's updates, including
>  kernel-2.6.10-1.1074_FC4, and rebooting,
>  (and before the kernel oops with a kernel
>  page fault):
>  
>  firefox refuses to start in enforcing mode. Here
>  are the AVCs:
>  
>  Jan  8 10:28:01 fedora kernel: audit(1105208881.086:0): avc:  denied 
>  { execmod } for  pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2
>  ino=3178514 scontext=user_u:user_r:user_t
>  tcontext=system_u:object_r:ld_so_t tclass=file
>  Jan  8 10:28:01 fedora kernel: audit(1105208881.831:0): avc:  denied 
>  { execmem } for  pid=4266 comm=firefox-bin
>  scontext=user_u:user_r:user_mozilla_t
>  tcontext=user_u:user_r:user_mozilla_t tclass=process
>  Jan  8 10:28:01 fedora kernel: audit(1105208881.928:0): avc:  denied 
>  { execmem } for  pid=4266 comm=firefox-bin
>  scontext=user_u:user_r:user_mozilla_t
>  tcontext=user_u:user_r:user_mozilla_t tclass=process
>  
>  Policy needs fixing for new kernel mods? 
New controls for executable mappings in SELinux, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=110200324503263&w=2.  The
upstream strict policy includes allow rules for user domains, but not
for mozilla, although I suppose this will have to change for
compatibility.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Stephen Smalley]

On Sat, 2005-01-08 at 13:41, Tom London wrote:
>  Running strict/enforcing, latest Rawhide.
>  
>  After downloading today's updates, including
>  kernel-2.6.10-1.1074_FC4, and rebooting,
>  (and before the kernel oops with a kernel
>  page fault):
>  
>  firefox refuses to start in enforcing mode. Here
>  are the AVCs:
>  
>  Jan  8 10:28:01 fedora kernel: audit(1105208881.086:0): avc:  denied 
>  { execmod } for  pid=4242 comm=java path=/lib/ld-2.3.4.so dev=hda2
>  ino=3178514 scontext=user_u:user_r:user_t
>  tcontext=system_u:object_r:ld_so_t tclass=file 
This one is suspect.  Can you reproduce with a kernel booted with
audit=1 enabled so that we can also get the syscall auditing information
for this denial?  Also, possibly run it under strace and collect the
output?

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Steve Thacker]

Immediately after the Kernel-2.6.10-737_FC3 update here, I couldn't get 
the  Firefox panel button (KDE)to startup Firefox, either (Firefox not 
something error, didn't read or save this notice, but just fixed the 
problem). After a little right click on the button and then properties, 
then application tab, then browsing to /usr/bin/firefox (the command box 
browse area button) it has worked just fine. New policy in this kernel 
that did away with the default panel button settings or what? Works just 
fine now tho.
Thanks to all the developers for Fedora Core, I have tried several Linux 
distro's and have settled on Fedora as it meets and exceeds all my needs 
from servers to browsers and Desktops. Looks real good too!!
thanks ya'll..............steve  w5set(a)alltel.net

Stephen Smalley wrote:

>  On Sat, 2005-01-08 at 13:41, Tom London wrote:
>  
> >Running strict/enforcing, latest Rawhide.
> >
> >After downloading today's updates, including
> >kernel-2.6.10-1.1074_FC4, and rebooting,
> >
> >firefox refuses to start in enforcing mode. Here
> >are the AVCs:
> >
>  
>  This one is suspect.  Can you reproduce with a kernel booted with
>  audit=1 enabled so that we can also get the syscall auditing information
>  for this denial?  Also, possibly run it under strace and collect the
>  output?
>

[Tom London]

>  > This one is suspect.  Can you reproduce with a kernel booted
> with
>  > audit=1 enabled so that we can also get the syscall auditing information
>  > for this denial?  Also, possibly run it under strace and collect the
>  > output?
>  >
>   
Uhhh..I came home, put libjavaplugin_oji.so  back into /usr/mozilla/plugins
(I had moved it into /usr/mozilla), and rebooted with audit=1 as your
suggested. 

I know this is going to sound crazy, but it no longer fails as before.
I'm running selinux-policy-strict-1.20.1-3 now (was running earlier
policy when I filed the report).

I see that mozilla_macros.te has
allow $1_mozilla_t self:process { execmem setrlimit setsched };

Could this have 'fixed' this?

tom

-- 
Tom London

[Tom London]

Sorry.... I'm also now running kernel 1076_FC4.

-- 
Tom London

[Stephen Smalley]

On Thu, 2005-01-13 at 01:24, Tom London wrote:
>  Uhhh..I came home, put libjavaplugin_oji.so  back into
> /usr/mozilla/plugins
>  (I had moved it into /usr/mozilla), and rebooted with audit=1 as your
>  suggested. 
>  
>  I know this is going to sound crazy, but it no longer fails as before.
>  I'm running selinux-policy-strict-1.20.1-3 now (was running earlier
>  policy when I filed the report).
>  
>  I see that mozilla_macros.te has
>  allow $1_mozilla_t self:process { execmem setrlimit setsched };
>  
>  Could this have 'fixed' this? 
I'm concerned about the execmod denial on ld.so, not the execmem
denials.  I think Dan added both to the policy, but we need to remove
the execmod rule and debug this further, because it seems wrong.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Tom London]

On Thu, 13 Jan 2005 10:45:56 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil&gt; wrote:
>  I'm concerned about the execmod denial on ld.so, not the execmem
>  denials.  I think Dan added both to the policy, but we need to remove
>  the execmod rule and debug this further, because it seems wrong.
>   
Understand.   I see the execmod rule in base_user_macros.te.

How can I help?

Would it be useful for me to remove the execmod rule for
ld_so_t from there and rerun with audit=1? Something else?

tom

-- 
Tom London

[Stephen Smalley]

On Thu, 2005-01-13 at 11:23, Tom London wrote:
>  Understand.   I see the execmod rule in base_user_macros.te.
>  
>  How can I help?
>  
>  Would it be useful for me to remove the execmod rule for
>  ld_so_t from there and rerun with audit=1? Something else? 
Yes.  And also to run it under strace (in permissive mode) and collect
the output to send to me.  However, this looks similar to me to 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505, except that
was caused by faulty logic in the mmap/mprotect hooks.  But reading the
comments in that bug report suggests that ld.so is being mapped writable
(in a private mapping) and modified, which would run into this execmod
check.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency