execmod avcs from today's policy

[Tom London]

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

[Stephen Smalley]

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.

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

[Stephen Smalley]

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.

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

[Stephen Smalley]

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).

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

[Tom London]

Excellent fix!

Thanks,
  tom

[Stephen Smalley]

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?

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

[Ivan Gyurdiev]

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

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Tom London]

On Fri, 28 Jan 2005 20:06:21 -0700, Ivan Gyurdiev <ivg2(a)cornell.edu&gt; 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
-- 
Tom London

[Ivan Gyurdiev]

>  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


-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Stephen Smalley]

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&....

>  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.

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

[Stephen Smalley]

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.

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