Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tech:linux_protection_de_l_espace_executable [2025/03/24 15:06] – créée - modification externe 127.0.0.1
+++ tech:linux_protection_de_l_espace_executable [2026/06/07 19:12] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+<!DOCTYPE markdown>
+{{tag>Brouillon Kernel Securité}}
+# Protection de l'espace exécutable
+Contre buffer overflow
+Voir :
+https://en.wikipedia.org/wiki/Executable_space_protection
+## Linux Address Space Layout Randomization (ASLR) et exec-shield
+Liens :
+* https://fr.wikipedia.org/wiki/Address_space_layout_randomization
+* https://en.wikipedia.org/wiki/Exec_Shield
+* https://docs.oracle.com/cd/E37670_01/E36387/html/ol_aslr_sec.html
+Kernel arguments pour désactiver
+~~~
+exec-shield=0 norandmaps
+~~~
+Pour désactiver que pour un seul processus
+~~~bash
+setarch $(uname -i) -R /opt/plop
+~~~
+----
+### Pour Oracle
+#### CAUSE
+Recent linux kernels have a feature called Address Space Layout Randomization (ASLR).
+ASLR  is a feature that is activated by default on some of the newer linux distributions.
+It is designed to load shared memory objects in random addresses.
+In Oracle, multiple processes map a shared memory object at the same address across the processes.
+With ASLR turned on Oracle cannot guarantee the availability of this shared memory address.
+This conflict in the address space means that a process trying to attach a shared memory object to a specific address may not be able to do so, resulting in a failure in shmat subroutine.
+However, on subsequent retry (using a new process) the shared memory attachment may work.
+The result is a "random" set of failures in the alert log.
+#### SOLUTION
+It should be noted that this problem has only been positively diagnosed in Redhat 5 and Oracle 11.2.0.2.
+It is also likely, as per unpublished BUG:8527473,  that this issue will reproduce running on Generic Linux platforms running  any Oracle 11.2.0.x. or 12.1.0.x  on Redhat/OEL kernels which have ASLR.
+This issue has been seen in both Single Instance and RAC environments.
+ASLR also exists in SLES10 and SLES 11 kernels and by default ASLR is turned on.  To date no problem has been seen on SuSE servers running Oracle  but Novell confirm ASLR may cause problems.  Please refer to
+http://www.novell.com/support/kb/doc.php?id=7004855 mmap occasionally infringes on stack
+You can verify whether ASLR is being used as follows:
+~~~
+# /sbin/sysctl -a | grep randomize
+kernel.randomize_va_space = 1
+~~~
+If the parameter is set to any value other than 0 then ASLR is in use.
+On Redhat 5 to permanently disable ASLR.
+add/modify this parameter in /etc/sysctl.conf
+/etc/sysctl.conf
+~~~bash
+kernel.randomize_va_space=0
+kernel.exec-shield=0
+~~~
+You need to reboot for kernel.exec-shield parameter to take effect.
+Note that both kernel parameters are required for ASLR to be switched off.
+There may be other reasons for a process failing to start, however, by switching ASLR off, you can quickly discount ASLR being the problem. More and more issues are being identified when ASLR is in operation.
+Note:  "In RHEL/OEL 7 exec-shield is not modifiable anymore, so changing the exec-shield parameter produces an error."
+----