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
Same problem in 1075_FC4.
Works (with similar AVCs) in permissive mode.
tom
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
Sorry, accidently booted 1063_FC4 by accident.
Still happens in 1075_FC4.
tom
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
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.
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?
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@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?
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
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.
On Thu, 13 Jan 2005 10:45:56 -0500, Stephen Smalley sds@epoch.ncsc.mil 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
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.
selinux@lists.fedoraproject.org
-
Stephen Smalley -
Steve Thacker -
Tom London