* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: hardened-debugging.xml hardenedfaq.xml index.xml
@ 2011-06-07 19:11 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; only message in thread
From: JosA MarAa Alonso (nimiux) @ 2011-06-07 19:11 UTC (permalink / raw
To: gentoo-commits
nimiux 11/06/07 19:11:45
Modified: hardenedfaq.xml index.xml
Added: hardened-debugging.xml
Log:
New spanish translation of hardened-debuging.xml
Revision Changes Path
1.9 xml/htdocs/proj/es/hardened/hardenedfaq.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?rev=1.9&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?rev=1.9&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?r1=1.8&r2=1.9
Index: hardenedfaq.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- hardenedfaq.xml 8 May 2011 11:53:15 -0000 1.8
+++ hardenedfaq.xml 7 Jun 2011 19:11:44 -0000 1.9
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v 1.8 2011/05/08 11:53:15 nimiux Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v 1.9 2011/06/07 19:11:44 nimiux Exp $ -->
<guide link="/proj/es/hardened/hardenedfaq.xml" lang="es">
<title>Preguntas de Uso Frecuente de Gentoo Hardened</title>
@@ -350,7 +350,7 @@
<body>
<p>
-Hemos escrito un <uri link="/proj/en/hardened/hardened-debugging.xml">
+Hemos escrito un <uri link="/proj/es/hardened/hardened-debugging.xml">
documento de cómo depurar en Gentoo Hardened</uri> (en inglés), por
lo que siguiendo las recomendaciones se debería solucionar el problema
que aparezca.
1.9 xml/htdocs/proj/es/hardened/index.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/index.xml?rev=1.9&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/index.xml?rev=1.9&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/index.xml?r1=1.8&r2=1.9
Index: index.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/index.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- index.xml 17 May 2011 19:36:09 -0000 1.8
+++ index.xml 7 Jun 2011 19:11:44 -0000 1.9
@@ -101,8 +101,8 @@
<resource link="/proj/en/hardened/roadmap.xml">
Hoja de ruta de Hardened (en inglés)
</resource>
-<resource link="/proj/en/hardened/hardened-debugging.xml">
-Depuración de Hardened (en inglés)
+<resource link="/proj/es/hardened/hardened-debugging.xml">
+Depuración en Gento Hardened
</resource>
<resource link="/proj/es/hardened/hardenedxorg.xml">
Usando Xorg en Gentoo Hardened
1.1 xml/htdocs/proj/es/hardened/hardened-debugging.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardened-debugging.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardened-debugging.xml?rev=1.1&content-type=text/plain
Index: hardened-debugging.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardened-debugging.xml,v 1.1 2011/06/07 19:11:44 nimiux Exp $ -->
<guide lang="es">
<title>Depuración en Gentoo Hardened</title>
<author title="Author">
<mail link="klondike@xiscosoft.es">klondike</mail>
</author>
<author title="Contributor">
<!-- Via bugs #341889 and 265693 -->
Hugo Mildenberger
</author>
<author title="Traductor">
<mail link="nimiux"/>
</author>
<abstract>
En este documento estudiaremos las formas de realizar un depurado binario
correcto cuando estemos usando un núcleo hardened y una cadena de
herramientas con PaX/Grsec, PIE y SSP.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.0</version>
<date>2010-10-26</date>
<chapter>
<title>Resolviendo la cuestión '??'</title>
<section>
<body>
<p>
Cuando esté depurando, probablemente se haya encontrado que <c>GDB</c>
puede que no muestre las direcciones, y en su lugar aparezcan líneas con
<e>'??'</e> donde debería aparecer el símbolo. Esto puede deberse a dos
cosas diferentes.
</p>
<p>
La primera causa es que su versión de <c>GDB</c> es demasiado antigua y no
tiene en cuenta que las direcciones son relativas. Esto debería estar
corregido en la versión actual estable de <c>GDB</c> de modo que debería
actualizarla. Otra forma de corregir el problema es aplicar la solución 3.
</p>
<p>
La segunda razón puede ser que su núcleo hardened está ocultando los mapeos.
Este problema es bien conocido y <uri
link="http://forums.grsecurity.net/viewtopic.php?f=1&t=2467" >ha sido
corregido por el equipo de desarrollo principal</uri> por lo que será
corregido en futuras versiones de <c>hardened-sources</c>. De todos modos,
hasta que esta corrección llegue al árbol y sea estabilizada, puede aplicar
cualquiera de las soluciones.
</p>
</body>
</section>
<section>
<title>Solución 1: Deshabilitar RANDMMAP en el binario</title>
<body>
<p>
Una solución consiste en deshabilitar la característica RANDMMAP con
<c>paxctl</c> en ese binario en particular. Al hacer esto, Grsec
deshabilitará la protección del mapeo para ese binario ya que no tiene
ningún sentido conservarla en este caso. Esto se traduce en un entorno
más seguro pero también se alejará de la forma en que el binario se
ejecutaría en un entorno real.
</p>
<pre caption="Deshabilitar RANDMMAP con paxctl">
# <i>paxctl -r binario</i>
</pre>
</body>
</section>
<section>
<title>Solución 2: Deshabilitando la opción para ocultar los mapeos</title>
<body>
<p>
Otra forma de corregir el problema es deshabilitar la opción que oculta
las direcciones en los ejecutables protegidos por PaX para evitar
ataques basados en esa información. Esta opción puede facilitar las
cosas a un atacante hasta que se habilite de nuevo aunque también
significa que el entorno será lo más parecido al entorno real de
ejecución.
</p>
<pre caption="Deshabilitar la ocultación del mapeo">
Address Space Protection --->
[ ] Remove addresses from /proc/<pid>/[smaps|maps|stat]
</pre>
</body>
</section>
<section>
<title>Solución 3: Enlazar un binario no PIE</title>
<body>
<p>
Una última solución consiste en deshabilitar la última fase de enlazado
pie en el momento de la compilación usando <c>-nopie</c>. Las
compilaciones anteriores pueden seguir usando <c>-fPIE</c> de forma
normal (lo cual es también el comportamiento por defecto del compilador
hardened), así, su ejecutable está en la situación más próxima a la
realidad ya que el enlazado final creará un ejecutable normal.
<br />
Intente añadir <c>-nopie</c> a LDFLAGS si construye los binarios usando
emerge.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Usar puntos de ruptura (breakpoints)</title>
<section>
<body>
<p>
Puede encontrarse con que PaX evita que <c>GDB</c> defina los puntos de
ruptura software, dependiendo de cómo se haya configurado el núcleo.
Esto incluye el punto de ruptura en la función principal (main) en la
que necesitará comenzar. Existen dos formas de evitar esto con
diferentes efectos y restricciones para resolverlo.
</p>
</body>
</section>
<section>
<title>Solución 1: Eliminando los ajustes RANDEXEC y MPROTECT</title>
<body>
<p>
La primera solución consiste en hacer que PaX deshabilite las
características RANDEXEC y MPROTECT para el binario que se quiere depurar.
Para hacer esto tendrá que hacer que <c>paxctl</c> utilice las opciones
<c>m</c> y <c>x</c> en el ejecutable. La opción <c>x</c> se utiliza por
defecto, por lo que basta con hacer:
</p>
<pre caption="Deshabilitar MPROTECT">
# <i>/sbin/paxctl -m binario</i>
</pre>
<p>
Después de esto, <c>GDB</c> debería poder añadir puntos de ruptura
software en el binario, si por alguna razón no puede hacerlo, intente
deshabilitar las características SEGMEXEC y PAGEEXEC (opciones <c>s</c>
y <c>p</c> respectivamente).
</p>
<pre caption="Deshabilitar SEGMEXEC y PAGEEXEC">
# <i>/sbin/paxctl -ps binario</i>
</pre>
<p>
Abajo mostramos qué es lo que ocurre a un nivel inferior cuando se
añade un punto de ruptura software, y porqué PaX desactiva esto.
Necesita conocer a grandes rasgos cómo funciona un procesador para
comprenderlo. Esto no es necesario para resolver el problema por lo
que si quiere puede ignorarlo.
</p>
<p>
Cuando el depurador añade un punto de ruptura software, cambia la
instrucción en la imagen de memoria del ejecutable para que sea una
instrucción de punto de ruptura (en los procesadores x86 y amd64
estas instrucciones son <c>bp</c> y <c>bu</c>). Esta instrucción detiene
el procesador y le da el control al depurador y tiene la ventaja
de que se puede colocar en un número ilimitado de puntos del programa.
Debido a que PaX no permite la escritura en la memoria ejecutable por
razones de seguridad, es imposible que el depurador modifique el código
y añada el punto de ruptura.
</p>
</body>
</section>
<section>
<title>Solución 2: Usando puntos de ruptura hardware</title>
<body>
<p>
Otra solución consiste en el uso de puntos de ruptura hardware, éstos no
requieren ningún cambio en el comportamiento de PaX, pero normalmente
su uso está limitado (por ejemplo a un máximo de cuatro en los procesadores
x86 y amd64 incluyendo los puntos de vigilancia (watchpoints) de
direcciones), además tienen el problema de que necesitan que el programa
ya esté en ejecución para que se puedan añadir (aunque existe algún
trabajo en proceso para corregir esto en <c>GDB</c>).
</p>
<p>
Para definirlos, utilice la orden <c>hbreak</c> en lugar de <c>break</c>.
</p>
<p>
Debajo mostramos qué ocurre a un nivel inferior cuando se añade un punto
de ruptura hardware. Necesita conocer a grandes rasgos cómo funciona un
procesador para comprenderlo. Esto no es necesario para resolver el
problema por lo que si quiere puede ignorarlo.
</p>
<p>
Cunado un depurador añade un punto de ruptura hardware, cambia algunos
de los registros del procesador (en los procesadores x86 y amd64 estos
registros se llaman Dr) por lo que el procesador se detiene cuando se
accede a cierta dirección (bien sea para leer su contenido, escribir en
ella o ejecutar el código que contiene). Como resultado no hay porqué
escribir ningún dato en la memoria solucionando el problema que
se planteaba con los puntos de ruptura software, pero también se
limita el número de puntos de ruptura disponibles.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Restaurando el fichero después del depurado</title>
<section>
<body>
<p>
Después del depurado, puede que querer restaurar el sistema a su estado
normal, si usó <c>paxctl</c> puede dejar las opciones como estaban por
defecto usando la opción <c>-z</c>.
</p>
<pre caption="Volviendo a dejar las opciones a sus valores por defecto">
# <i>paxctl -z binario</i>
</pre>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-06-07 19:11 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-07 19:11 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: hardened-debugging.xml hardenedfaq.xml index.xml JosA MarAa Alonso (nimiux)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox