Bug 182965 - mono needs execmen to execute causes selinux failures.
mono needs execmen to execute causes selinux failures.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
: Security
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-02-24 14:55 EST by Daniel Walsh
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-03 18:14:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
mono-compiler.patch (2.01 KB, patch)
2006-02-24 15:50 EST, Jakub Jelinek
no flags Details | Diff
amd64 fix (793 bytes, patch)
2006-02-28 08:40 EST, Paolo Molaro
no flags Details | Diff
fully fleshed out patch (2.18 KB, patch)
2006-03-02 16:40 EST, Ray Strode [halfline]
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Ximian Software (Novell) 77653 None None None Never

  None (edit)
Description Daniel Walsh 2006-02-24 14:55:28 EST
Description of problem:

mono requires execmem to run.  SELinux can not happen because the executable
needs execment to even get started.

readelf -l /usr/bin/mono

Elf file type is EXEC (Executable file)
Entry point 0x805c330
There are 9 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x194bab 0x194bab R E 0x1000
  LOAD           0x195000 0x081dd000 0x081dd000 0x00ffe 0x0f7fc RWE 0x1000
  DYNAMIC        0x1953d8 0x081dd3d8 0x081dd3d8 0x00110 0x00110 RW  0x4
  NOTE           0x000168 0x08048168 0x08048168 0x00020 0x00020 R   0x4
  TLS            0x195000 0x081dd000 0x081dd000 0x00000 0x00014 R   0x4
  GNU_EH_FRAME   0x176624 0x081be624 0x081be624 0x065d4 0x065d4 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr
.eh_frame .gcc_except_table
   03     .ctors .dtors .jcr .data.rel.ro .dynamic .got .got.plt .data writetext
.bss
   04     .dynamic
   05     .note.ABI-tag
   06     .tbss
   07     .eh_frame_hdr
   08
Comment 1 Daniel Walsh 2006-02-24 14:57:41 EST
Basically I get an execmem failure from unconfined_t before mono starts.  If I
allow execmem in SELinux mono will transition to mono_t but I get an auditallow
granted message for unconfined_t.

Comment 2 Daniel Walsh 2006-02-24 15:00:31 EST
Nalin and I looked into this further and we think the culprit is the following:

=======================================================================
Dan, it looks like the 'mono' binary defines a segment named 'writetext'
like so (mono/mini/mini.c:7268, preprocessed):

   static __thread gpointer mono_lmf_addr __attribute__((tls_model("local-exec")));
   gint32
   mono_get_lmf_tls_offset (void)
   {
     int offset;
     __asm ("jmp 1f; .section writetext, \"awx\"; 1: movl $" "mono_lmf_addr"
"@ntpoff, %0; jmp 2f; .previous; 2:" : "=r" (offset));;
     return offset;
   }

And the run-time linker is probably just hitting the execmem denial as
part of doing its job. 
Comment 3 Stephen Smalley 2006-02-24 15:05:01 EST
ELF file has a RWE segment, which triggers the denial when the kernel ELF loader
tries to mmap it with those protections, IIUC.  This happens prior to switching
credentials, so it happens in the caller's context rather than the new domain.
Build or code problem in mono.
Comment 4 Jakub Jelinek 2006-02-24 15:50:46 EST
Created attachment 125213 [details]
mono-compiler.patch
Comment 6 Daniel Walsh 2006-02-24 16:45:53 EST
Applyin jakub's patch to the latest mono and rebuilding seems to have cleaned up
the problem.  tomboy is working fine with the new vesion.
Comment 7 Ray Strode [halfline] 2006-02-27 12:21:44 EST
File upstream here: http://bugzilla.ximian.com/show_bug.cgi?id=77653
Comment 8 Paolo Molaro 2006-02-28 08:40:17 EST
Created attachment 125396 [details]
amd64 fix

You need this additional patch to make mono compile and work on amd64 systems.
Thanks.
Comment 9 Jakub Jelinek 2006-02-28 08:58:23 EST
Yeah, my patch was completely untested, doesn't surprise me I made one typo.
Also, IA-64 probably needs similar treatment, i.e. use the current __asm
for non-pic and for PIC use
__asm ("addl %0 = @ltoff(@tprel(" #var "#)), gp ;; ld8 %0 = [%0]\n" : "=r"
(offset))
Comment 10 Ray Strode [halfline] 2006-03-02 16:40:02 EST
Created attachment 125569 [details]
fully fleshed out patch

Hi,

Above, is the patch I built into rawhide.  It has the x86-64 update and the
ia64 update in it.  Can you guys verify that it looks correct?
Comment 11 Ray Strode [halfline] 2006-03-03 18:14:43 EST
Hey guys,

I'm going to close this bug, but if anyone experiences it again, feel free to
reopen.

Note You need to log in before you can comment on or make changes to this bug.