Running strict/enforcing, today's Rawhide.
Noticed the avcs below in the log.
I believe the java one may be from the sun JVM I have installed.... xscreensaver and helixplayer ones are new.
My understanding is that I need to set the boolean 'allow_execmod' to allow this kind of thing (although nothing appears broken....)
Do I have that correct?
tom
Jan 28 07:54:36 fedora gdm(pam_unix)[3218]: session opened for user tbl by (uid=0) Jan 28 07:54:48 fedora kernel: audit(1106927688.744:0): avc: denied { execmod } for pid=3491 comm=xscreensaver-gl path=/usr/X11R6/lib/libGL.so.1.2 dev=hda2 ino=4127021 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 ino=3178539 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:19 fedora kernel: audit(1106927719.841:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/swfrender.so dev=hda2 ino=4375247 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:21 fedora kernel: audit(1106927721.289:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/oggfformat.so dev=hda2 ino=4376641 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:21 fedora kernel: audit(1106927721.316:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/theorarend.so dev=hda2 ino=4376654 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file Jan 28 07:55:22 fedora kernel: audit(1106927722.757:0): avc: denied { execmod } for pid=3650 comm=hxplay.bin path=/usr/lib/helix/plugins/vorbisrend.so dev=hda2 ino=4376655 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
On Fri, 2005-01-28 at 11:38, Tom London wrote:
Running strict/enforcing, today's Rawhide.
Noticed the avcs below in the log.
I believe the java one may be from the sun JVM I have installed.... xscreensaver and helixplayer ones are new.
My understanding is that I need to set the boolean 'allow_execmod' to allow this kind of thing (although nothing appears broken....)
Do I have that correct?
I think that the allow_execmod boolean only allows execmod permission to files labeled with the new texrel_shlib_t type. Or at least that is what it should do. Any existing occurrences of execmod permission in the policy should be changed to use texrel_shlib_t now that it is defined, and then any DSOs that require it should be relabeled to that type.
On Fri, 2005-01-28 at 13:12, Stephen Smalley wrote:
I think that the allow_execmod boolean only allows execmod permission to files labeled with the new texrel_shlib_t type. Or at least that is what it should do. Any existing occurrences of execmod permission in the policy should be changed to use texrel_shlib_t now that it is defined, and then any DSOs that require it should be relabeled to that type.
We should also wrap occurrences of execmem with a boolean, but a separate one than the execmod rules. Might also want multiple booleans, e.g. to allow certain programs without allowing all others.
On Fri, 2005-01-28 at 13:35, Stephen Smalley wrote:
We should also wrap occurrences of execmem with a boolean, but a separate one than the execmod rules. Might also want multiple booleans, e.g. to allow certain programs without allowing all others.
Note: An allow_execmem boolean has been introduced into the latest upstream policy, so I expect it will show up in future Fedora policies. Hence, you may need to enable this boolean, e.g. to allow X to continue to run. In the future, I think we will want multiple such booleans so that we can allow certain domains (like X) to have this permission while prohibiting others (like user domains).
On Fri, 2005-01-28 at 11:38, Tom London wrote:
Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 ino=3178539 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
Naturally, relabeling libc to texrel_shlib_t isn't an option. Likewise for ld.so. java needs to run in its own domain so that we only have to give execmod to shlib_t to specific domains, not the base user domain. Care to make one?
On Fri, 2005-01-28 at 13:55 -0500, Stephen Smalley wrote:
On Fri, 2005-01-28 at 11:38, Tom London wrote:
Jan 28 07:54:57 fedora kernel: audit(1106927697.979:0): avc: denied { execmod } for pid=3549 comm=java path=/lib/libc-2.3.4.so dev=hda2 ino=3178539 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
Naturally, relabeling libc to texrel_shlib_t isn't an option. Likewise for ld.so. java needs to run in its own domain so that we only have to give execmod to shlib_t to specific domains, not the base user domain. Care to make one?
What exactly is causing this denial... I see two more like it:
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
and
audit(1106936406.702:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file audit(1106936406.798:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
On Fri, 28 Jan 2005 20:06:21 -0700, Ivan Gyurdiev ivg2@cornell.edu wrote:
What exactly is causing this denial... I see two more like it:
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
and
audit(1106936406.702:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file audit(1106936406.798:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
Here's my understanding:
The new kernel/policy can now enforce controls on the modification to memory mapped regions that can be executed. I think this is a very good thing.....
However, existing code/applications do funny things with such memory mapped regions (like writing one word, like relocating, like ....), so we get these AVCs for them.
There seem to be two approaches to fix: first, fix the apps (I believe you need new tool chain at least, or am I getting confused....), and now that there policy support, create policy specs for the apps that need it.
In my case, I see these for the Sun Jave JVM I have installed. In your case, looks like 'setiathome' and 'ut2004' are the culprits.
Do I have this correct? tom
However, existing code/applications do funny things with such memory mapped regions (like writing one word, like relocating, like ....), so we get these AVCs for them.
But that's a different kind of execmod denial than others I've seen - I thought libs with text relocations all had this TEXTREL tag...
[phantom@cobra ~]$ readelf -d /usr/lib/libSDL-1.2.so.0.7.0|grep TEXTREL 0x00000016 (TEXTREL) 0x0
On Sat, 2005-01-29 at 11:56, Tom London wrote:
The new kernel/policy can now enforce controls on the modification to memory mapped regions that can be executed. I think this is a very good thing.....
execmem permission controls the ability to make executable an anonymous mapping or a writable private file mapping. execmod permission controls the ability to make executable a previously modified private file mapping. The controls were introduced in http://marc.theaimsgroup.com/?l=bk-commits-head&m=110491550432114&w=....
However, existing code/applications do funny things with such memory mapped regions (like writing one word, like relocating, like ....), so we get these AVCs for them.
The dynamic linker needs to write one word; normally, this isn't a problem as the mapping in question is not executable. However, for legacy binaries, the read protection is translated to read|execute, which then triggers the checks.
There seem to be two approaches to fix: first, fix the apps (I believe you need new tool chain at least, or am I getting confused....), and now that there policy support, create policy specs for the apps that need it.
Newer tool chain will at least try to classify the application and mark it accordingly. Modifications to the application or its build may be necessary to avoid unnecessarily lax marking.
In my case, I see these for the Sun Jave JVM I have installed. In your case, looks like 'setiathome' and 'ut2004' are the culprits.
Do I have this correct?
Yes.
On Fri, 2005-01-28 at 22:06, Ivan Gyurdiev wrote:
What exactly is causing this denial... I see two more like it:
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file
audit(1106919680.669:0): avc: denied { execmod } for pid=26098 comm=setiathome path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
and
audit(1106936406.702:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=115333 scontext=user_u:user_r:user_t tcontext=system_u:object_r:shlib_t tclass=file audit(1106936406.798:0): avc: denied { execmod } for pid=669 comm=ut2004-bin path=/lib/ld-2.3.4.so dev=dm-0 ino=113630 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
Legacy binaries (those that lack PT_GNU_STACK on x86) have PROT_READ mmap/mprotect requests automatically translated to PROT_READ|PROT_EXEC for backward compatibility. The dynamic linker needs to modify one word in the mapping, so the linker makes it writable, modifies the word, and changes it back to read-only. But since it is a legacy binary, the kernel views the latter as an attempt to make executable a mapping that was previously modified, and triggers the execmod permission check on it. Such legacy binaries should be placed into a separate domain so that they can be separately confined.
selinux@lists.fedoraproject.org