| 1 |
nimiux 12/07/02 17:55:55 |
| 2 |
|
| 3 |
Modified: primer.xml |
| 4 |
Log: |
| 5 |
Fixed revision date. Fixed line wrapping. Modified links to translated guides |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.2 xml/htdocs/proj/es/hardened/primer.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/primer.xml?rev=1.2&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/primer.xml?rev=1.2&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/primer.xml?r1=1.1&r2=1.2 |
| 13 |
|
| 14 |
Index: primer.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/primer.xml,v |
| 17 |
retrieving revision 1.1 |
| 18 |
retrieving revision 1.2 |
| 19 |
diff -u -r1.1 -r1.2 |
| 20 |
--- primer.xml 23 Dec 2005 14:43:28 -0000 1.1 |
| 21 |
+++ primer.xml 2 Jul 2012 17:55:55 -0000 1.2 |
| 22 |
@@ -15,10 +15,13 @@ |
| 23 |
<author title="Traductor"> |
| 24 |
<mail link="anpereir@g.o">Andrés Pereira</mail> |
| 25 |
</author> |
| 26 |
+<author title="Traductor"> |
| 27 |
+ <mail link="nimiux"/> |
| 28 |
+</author> |
| 29 |
|
| 30 |
<abstract>Un compendio acerca de Gentoo Hardened</abstract> |
| 31 |
<version>1.2</version> |
| 32 |
-<date>2005-10-10</date> |
| 33 |
+<date>2007-02-07</date> |
| 34 |
|
| 35 |
<chapter> |
| 36 |
<title>Introducción</title> |
| 37 |
@@ -26,37 +29,39 @@ |
| 38 |
<body> |
| 39 |
|
| 40 |
<p> |
| 41 |
-Esta guía está orientada a cualquier usuario que esté inseguro de las cosas que |
| 42 |
-ofrece el proyecto Gentoo Hardened, de cómo usarlas juntas y cuáles son sus |
| 43 |
-respectivos roles en el proyecto. |
| 44 |
+Esta guía está orientada a cualquier usuario que esté inseguro de las |
| 45 |
+cosas que ofrece el proyecto Gentoo Hardened, de cómo usarlas |
| 46 |
+conjuntamente y cuáles son sus respectivos roles en el proyecto. |
| 47 |
</p> |
| 48 |
|
| 49 |
<p> |
| 50 |
-El principio básico de seguridad que enfatizamos es el de capas de seguridad. |
| 51 |
-Las capas son fundamentales en asegurar que no se vea comprometida la máquina de |
| 52 |
-un usuario, y si lo está, minimizar los daños hechos. Mediante la combinación de |
| 53 |
-una serie de tecnologías diferentes, no obstante, relacionadas a seguridad, |
| 54 |
-hacemos que un atacante tenga que saltar pasos adicionales antes de que pueda |
| 55 |
-ocurrir un incidente de compromiso. Por esta razón siempre recomendamos que |
| 56 |
-decida cuáles son sus necesidades específicas y combine esas soluciones para |
| 57 |
-proteger su sistema. Intentaremos explicar las opciones y cómo usarlas juntas en |
| 58 |
-este documento. |
| 59 |
+El principio básico de seguridad que enfatizamos es el de capas de |
| 60 |
+seguridad. Las capas son fundamentales en asegurar que no se vea |
| 61 |
+comprometida la máquina de un usuario, y si lo está, minimizar los |
| 62 |
+daños hechos. Mediante la combinación de una serie de tecnologías |
| 63 |
+diferentes, no obstante, relacionadas a seguridad, hacemos que un |
| 64 |
+atacante tenga que saltar pasos adicionales antes de que pueda |
| 65 |
+ocurrir un incidente de compromiso. Por esta razón siempre recomendamos |
| 66 |
+que decida cuáles son sus necesidades específicas y combine esas |
| 67 |
+soluciones para proteger su sistema. Intentaremos explicar las opciones |
| 68 |
+y cómo usarlas conjuntamente en este documento. |
| 69 |
</p> |
| 70 |
|
| 71 |
-<p> |
| 72 |
+<p> |
| 73 |
Gentoo Hardened no es un producto o solución por si mismo, es meramente un |
| 74 |
-proyecto formado por un grupo de desarrolladores que trabajan con un mismo |
| 75 |
-objetivo: seguridad muy proactiva. Los subproyectos contenidos en Gentoo |
| 76 |
-Hardened no están relacionados salvo por el hecho de que están alojados dentro |
| 77 |
-del mismo proyecto. Puede pensar que esto es parecido a KDE o GNOME en el |
| 78 |
-sentido de que ambos son partes del proyecto de escritorio, y que los dos |
| 79 |
-tienen un objetivo común pero no están relacionados del todo uno con el otro. |
| 80 |
-</p> |
| 81 |
- |
| 82 |
-<note> |
| 83 |
-Pedir ayuda para instalar o tener soporte de su máquina 'Gentoo Hardened' no es |
| 84 |
-claro y siempre debería aclarar que tiene un problema de SELinux, PIE/SSP, |
| 85 |
-etcétera. |
| 86 |
+proyecto formado por un grupo de desarrolladores que trabajan con un mismo |
| 87 |
+objetivo: seguridad muy proactiva. Los subproyectos contenidos en Gentoo |
| 88 |
+Hardened no están relacionados salvo por el hecho de que están alojados |
| 89 |
+dentro del mismo proyecto. Puede pensar que esto es parecido a KDE o GNOME |
| 90 |
+en el sentido de que ambos son partes del proyecto de escritorio, y que |
| 91 |
+los dos tienen un objetivo común pero no están relacionados del todo uno |
| 92 |
+con el otro. |
| 93 |
+</p> |
| 94 |
+ |
| 95 |
+<note> |
| 96 |
+Pedir ayuda para instalar o tener soporte de su máquina 'Gentoo Hardened' |
| 97 |
+no es claro y siempre debería aclarar que tiene un problema de SELinux, |
| 98 |
+PIE/SSP, etc. |
| 99 |
</note> |
| 100 |
|
| 101 |
</body> |
| 102 |
@@ -69,63 +74,70 @@ |
| 103 |
<title>PaX</title> |
| 104 |
<body> |
| 105 |
<p> |
| 106 |
-En el corazón del proyecto se encuentra PaX. PaX es un parche para el núcleo que |
| 107 |
-le permite protegerse contra desbordamientos de búfer y del heap y ataques |
| 108 |
-similares. PaX es su primera línea de defensa. |
| 109 |
+En el corazón del proyecto se encuentra PaX. PaX es un parche para el |
| 110 |
+núcleo que le permite protegerse contra desbordamientos de búfer y del |
| 111 |
+montículo (heap) y ataques similares. PaX es su primera línea de defensa. |
| 112 |
</p> |
| 113 |
|
| 114 |
<p> |
| 115 |
-A causa del software malamente escrito siempre se está en riesgo de compromiso |
| 116 |
-por la posibilidad de que ocurran desbordamientos de búfer y del heap. Estas |
| 117 |
-dos vulnerabilidades son el resultado de límites no chequeados de la entrada que |
| 118 |
-un usuario realiza en las aplicaciones. Cuando un atacante tiene la capacidad de |
| 119 |
-generar una entrada en una aplicación tal que se inserte en la memoria pero sin |
| 120 |
-ser chequeada, existe la posibilidad de un desbordamiento. Los lenguajes de |
| 121 |
+A causa del software escrito de forma poco correcta, siempre se está en |
| 122 |
+riesgo de compromiso por la posibilidad de que ocurran desbordamientos |
| 123 |
+de búfer y del montículo. Estas dos vulnerabilidades son el resultado |
| 124 |
+de límites no chequeados de la entrada que un usuario realiza en las |
| 125 |
+aplicaciones. Cuando un atacante tiene la capacidad de generar una |
| 126 |
+entrada en una aplicación tal que se inserte en la memoria pero sin ser |
| 127 |
+chequeada, existe la posibilidad de un desbordamiento. Los lenguajes de |
| 128 |
programación de bajo nivel como C y C++ no protegen automáticamente de |
| 129 |
-saturaciones (overruns) y el resultado final es que cuando el búfer se satura da |
| 130 |
-la posibilidad de que el código ejecutable adyacente pueda ser sobreescrito con |
| 131 |
-la entrada que viene del usuario. Esto normalmente provocaría que la aplicación |
| 132 |
-se caiga en el caso que la entrada del usuario no sea entendida por la máquina |
| 133 |
-y generalmente se manifiesta como un fallo de página (page fault) porque los |
| 134 |
-caracteres que saturan el búfer en el área ejecutable serán tratados como |
| 135 |
-direcciones que probablemente nunca existirían. Este es el resultado más benigno |
| 136 |
-de una saturación. |
| 137 |
+desbordamientos y el resultado final es que cuando el búfer se satura |
| 138 |
+da la posibilidad de que el código ejecutable adyacente pueda ser |
| 139 |
+sobreescrito con la entrada que viene del usuario. Esto normalmente |
| 140 |
+provocaría que la aplicación se caiga en el caso que la entrada del |
| 141 |
+usuario no sea entendida por la máquina y generalmente se manifiesta |
| 142 |
+como un fallo de página (page fault) porque los caracteres que saturan |
| 143 |
+el búfer en el área ejecutable se tratan como direcciones que |
| 144 |
+probablemente nunca existirían. Este es el resultado más benigno de |
| 145 |
+una saturación. |
| 146 |
</p> |
| 147 |
|
| 148 |
<p> |
| 149 |
-Sin embargo, si el atacante sabe de una saturación tendrá la oportunidad de |
| 150 |
-añadir shellcode a la entrada y en vez de causar que la aplicación se caiga, |
| 151 |
-esta en cambio ejecutará las instrucciones dadas. Esto sucede debido a que el |
| 152 |
-shellcode se trata de cómo se almacenan las instrucciones en memoria para ser |
| 153 |
-ejecutadas por el procesador. En términos básicos, el shellcode consiste de |
| 154 |
-'códigos de operación' (opcodes) que se traducen a rutinas en ensamblador. Los |
| 155 |
-atacantes conocen estos códigos muy bien y pueden crear shellcode que les |
| 156 |
-permita hacer lo que deseen, tal como ejecutar un shell root y asociarlo |
| 157 |
-a un puerto. Cuando esto pasa, el usuario ni siquiera se dará cuenta de aquello |
| 158 |
-porque la aplicación no se cae sino que empieza ejecutando el código |
| 159 |
-arbitrario de los atacantes permitiéndoles hacer lo que se les plazca. PaX |
| 160 |
-mitiga este problema colocando de forma aleatoria cada función y búfer de |
| 161 |
-una aplicación en memoria. Esto es lo que se denomina ASLR (siglas en inglés de |
| 162 |
-Address Space Layout Randomization, Aleatorización de Distribución del Espacio de |
| 163 |
-Memoria) y es la base de PaX. Al tener offsets aleatorios para las funciones y |
| 164 |
-búferes, el atacante es incapaz de generar una entrada maliciosa que garantice |
| 165 |
-que el shellcode será ejecutado (y lo hace muy difícil puesto que la aplicación |
| 166 |
-probablemente se caerá y se reiniciará con nuevos offsets aleatorios). ASLR es |
| 167 |
-mucho más útil cuando se usa en conjunto con código PIE (Position Independent |
| 168 |
-Executable, Ejecutable Independiente de la Posición) pero también funciona con |
| 169 |
-el código ejecutable estándar, con un sobrecosto (overhead). |
| 170 |
+Sin embargo, si el atacante conoce un ataque por desbordamiento, tendrá |
| 171 |
+la oportunidad de añadir shellcode a la entrada y en lugar de causar que |
| 172 |
+la aplicación se caiga, ésta en cambio ejecutará las instrucciones dadas. |
| 173 |
+Esto sucede debido a que el shellcode se trata cómo instrucciones |
| 174 |
+almacenadas en memoria para ser ejecutadas por el procesador. |
| 175 |
+En términos básicos, el shellcode consiste en 'códigos de operación' |
| 176 |
+(opcodes) que se traducen a rutinas en ensamblador. Los atacantes conocen |
| 177 |
+estos códigos muy bien y pueden crear un shellcode que les permita hacer |
| 178 |
+lo que deseen, tal como ejecutar un intérprete de comandos como root y |
| 179 |
+asociarlo a un puerto. Cuando sucede esto, el usuario ni siquiera se dará |
| 180 |
+cuenta de ello porque la aplicación no se cae sino que empieza ejecutando |
| 181 |
+el código arbitrario de los atacantes permitiéndoles hacer lo que se les |
| 182 |
+plazca. PaX mitiga este problema colocando de forma aleatoria cada |
| 183 |
+función y búfer de una aplicación en memoria. Esto es lo que se denomina |
| 184 |
+ASLR (siglas en inglés de Address Space Layout Randomization, |
| 185 |
+Aleatorización de Distribución del Espacio de Memoria) y es la base de |
| 186 |
+PaX. Al tener offsets aleatorios para las funciones y búferes, el |
| 187 |
+atacante es incapaz de generar una entrada maliciosa que garantice que |
| 188 |
+el shellcode será ejecutado (y lo hace muy difícil puesto que la |
| 189 |
+aplicación probablemente se caerá y se reiniciará con nuevos offsets |
| 190 |
+aleatorios). ASLR es mucho más útil cuando se usa en conjunto con código |
| 191 |
+PIE (Position Independent Executable, Ejecutable Independiente de la |
| 192 |
+Posición) pero también funciona con el código ejecutable estándar, con un |
| 193 |
+coste añadido. |
| 194 |
</p> |
| 195 |
|
| 196 |
<p> |
| 197 |
-PaX también ofrece a los segmentos ejecutables la capacidad de ser ejecutables y |
| 198 |
-no modificables, de igual manera a que los segmentos modificables puedan ser |
| 199 |
-modificables y no ejecutables. Esto es denominado pageexec. En procesadores de |
| 200 |
-la arquitectura x86 no hay forma de hacer esto a nivel de hardware ya que los |
| 201 |
-diseñadores de x86 juntaron las banderas de memoria para leer y ejecutar y así |
| 202 |
-ahorrar espacio. Debido a que una página puede ser escrita o leída y ejecutada, |
| 203 |
-no es útil ajustar los búferes como no ejecutables porque no podrían seguir |
| 204 |
-siendo leídos. Así que en x86 PaX emula este comportamiento a nivel de software, |
| 205 |
-el cual introduce un sobrecosto pero es muy útil para la seguridad. |
| 206 |
+PaX también ofrece a los segmentos ejecutables la capacidad de ser |
| 207 |
+ejecutables y no modificables, de igual manera a que los segmentos |
| 208 |
+modificables puedan ser modificables y no ejecutables. Esto es |
| 209 |
+denominado pageexec. En procesadores de la arquitectura x86 no hay |
| 210 |
+forma de hacer esto a nivel de hardware ya que los diseñadores de x86 |
| 211 |
+juntaron las banderas de memoria para leer y ejecutar y así ahorrar |
| 212 |
+espacio. Debido a que una página puede ser escrita o leída y ejecutada, |
| 213 |
+no es útil ajustar los búferes como no ejecutables porque no podrían |
| 214 |
+seguir siendo leídos. Así que en x86 PaX emula este comportamiento a |
| 215 |
+nivel de software, el cual introduce un costo añadido pero es muy útil |
| 216 |
+para la seguridad. |
| 217 |
</p> |
| 218 |
</body> |
| 219 |
</section> |
| 220 |
@@ -135,31 +147,34 @@ |
| 221 |
<body> |
| 222 |
|
| 223 |
<p> |
| 224 |
-Por motivos de claridad, mientras que PIE y SSP generalmente son agrupados en la |
| 225 |
-misma discusión porque ambos son parte del toolchain de Hardened, ciertamente |
| 226 |
-son tecnologías diferentes con propósitos distintos. PIE por si mismo no provee |
| 227 |
-seguridad adicional pero cuando se combina con PaX en el núcleo sí provee una |
| 228 |
-herramienta poderosa contra los desbordamientos. SSP está implementado |
| 229 |
-íntegramente en el espacio del usuario (userland) y protege contra ataques de |
| 230 |
-quebrar la pila (stack smashing attacks) sin la ayuda del núcleo. Al estar |
| 231 |
-implementados separadamente y hacen cosas distintas, ciertamente son dos capas |
| 232 |
-diferentes de protección, por ejemplo, uno ataque denominado ret2libc puede |
| 233 |
-esquivar a PaX pero sería bloqueado por SSP. |
| 234 |
+Por motivos de claridad, mientras que PIE y SSP generalmente son |
| 235 |
+agrupados en la misma discusión porque ambos son parte de la cadena de |
| 236 |
+herramientas de Hardened, ciertamente son tecnologías diferentes con |
| 237 |
+propósitos distintos. PIE por si mismo no provee seguridad adicional |
| 238 |
+pero cuando se combina con PaX en el núcleo sí provee una herramienta |
| 239 |
+poderosa contra los desbordamientos. SSP está implementado íntegramente |
| 240 |
+en el espacio del usuario (userland) y protege contra ataques de quebrar |
| 241 |
+la pila (stack smashing attacks) sin la ayuda del núcleo. Al estar |
| 242 |
+implementados separadamente y hacen cosas distintas, ciertamente son |
| 243 |
+dos capas diferentes de protección, por ejemplo, uno ataque denominado |
| 244 |
+ret2libc puede esquivar a PaX pero sería bloqueado por SSP. |
| 245 |
</p> |
| 246 |
|
| 247 |
<p> |
| 248 |
-Hemos avanzado a grandes pasos para proveer una forma fácil de |
| 249 |
-construir la totalidad de las herramientas del espacio del usuario con código |
| 250 |
-PIE para aprovecharse de ASLR con muy poco sobrecosto. Adicionalmente a PIE, |
| 251 |
-nuestro toolchain Hardened también ofrece SSP (Stack Smashing Protection, |
| 252 |
-Protección contra el Quiebre de la Pila) mediante la ubicación de un área |
| 253 |
-externa de los búferes y colocando una marca especial aleatoria y criptográfica. |
| 254 |
-Esto permite a SSP chequear si es que la marca fue sobreescrita luego de |
| 255 |
-cualquier escritura al búfer y le permite terminar abruptamente la aplicación |
| 256 |
-en caso de haber sido sobreescrita dicha marca. El toolchain de Hardened da |
| 257 |
-a los usuarios un espacio PIE/SSP de la forma más fácil posible. Las fases |
| 258 |
-(stages) marcadas con 'pie-ssp' son fases estándares construidas con PIE y SSP, |
| 259 |
-no incluyen controles de acceso SELinux/RSBAC/grsecurity. |
| 260 |
+Hemos avanzado a grandes pasos para proveer una forma fácil de construir |
| 261 |
+la totalidad de las herramientas del espacio del usuario con código PIE |
| 262 |
+para aprovecharse de ASLR con muy poco sobrecosto. Adicionalmente a PIE, |
| 263 |
+nuestra cadena de herramientas Hardened también ofrece SSP (Stack |
| 264 |
+Smashing Protection, Protección contra el Quiebre de la Pila) mediante |
| 265 |
+la ubicación de un área externa de los búferes y colocando una marca |
| 266 |
+especial aleatoria y criptográfica. Esto permite a SSP chequear si es |
| 267 |
+que la marca fue sobreescrita luego de cualquier escritura al búfer y le |
| 268 |
+permite terminar abruptamente la aplicación en caso de haber sido |
| 269 |
+sobreescrita dicha marca. La cadena de herramientas de Hardened ofrece |
| 270 |
+a los usuarios un espacio PIE/SSP de la forma más fácil posible. |
| 271 |
+Las fases (stages) marcadas con 'pie-ssp' son fases estándares |
| 272 |
+construidas con PIE y SSP, no incluyen controles de acceso |
| 273 |
+SELinux/RSBAC/grsecurity. |
| 274 |
</p> |
| 275 |
</body> |
| 276 |
</section> |
| 277 |
@@ -169,35 +184,39 @@ |
| 278 |
<body> |
| 279 |
|
| 280 |
<p> |
| 281 |
-Aunque PaX es la primera capa de protección, quizás incluso la segunda o |
| 282 |
-tercera si tiene cortafuegos y/o detectores de intrusión en la red, también se |
| 283 |
-recomienda que use control de acceso para dar seguridad adicional a su |
| 284 |
-sistema. Es muy importante que note que el control de acceso como su |
| 285 |
-<b>última</b> capa de protección. El control de acceso es muy útil para evitar |
| 286 |
-el paso a los atacantes que ya ingresaron a su sistema, o a usuarios locales. |
| 287 |
-Actualmente Gentoo Hardened soporta 3 soluciones de control de acceso: SELinux, |
| 288 |
-grsecurity y RSBAC. SELinux requiere de cambios en el espacio del usuario lo que |
| 289 |
-significa que construimos fases (stages) especiales para SELinux y que no deben |
| 290 |
-ser confundidas con las fases pie-ssp. Sin embargo, ya que es recomendado el |
| 291 |
-uso de fases pie-ssp con SELinux, también se ofrecen fases selinux-pie-ssp. |
| 292 |
+Aunque PaX es la primera capa de protección, quizás incluso la segunda |
| 293 |
+o tercera si tiene cortafuegos y/o detectores de intrusión en la red, |
| 294 |
+también se recomienda que use control de acceso para dar seguridad |
| 295 |
+adicional a su sistema. Es muy importante que note que el control de |
| 296 |
+acceso como su <b>última</b> capa de protección. El control de acceso |
| 297 |
+es muy útil para evitar el paso a los atacantes que ya ingresaron a su |
| 298 |
+sistema, o a usuarios locales. Actualmente Gentoo Hardened soporta tres |
| 299 |
+soluciones de control de acceso: SELinux, grsecurity y RSBAC. SELinux |
| 300 |
+requiere de cambios en el espacio del usuario lo que significa que |
| 301 |
+construimos fases (stages) especiales para SELinux y que no deben ser |
| 302 |
+confundidas con las fases pie-ssp. Sin embargo, ya que es recomendado el |
| 303 |
+uso de fases pie-ssp con SELinux, también se ofrecen fases |
| 304 |
+selinux-pie-ssp. |
| 305 |
</p> |
| 306 |
|
| 307 |
<p> |
| 308 |
-Si desea usar grsecurity no tiene de qué preocuparse acerca de las fases ya que |
| 309 |
-no requiere de cambios en el espacio del usuario. Simplemente use las fases |
| 310 |
-pie-ssp y una vez que esté listo para construir el núcleo, use uno que tenga |
| 311 |
-activado grsecurity tal como las fuentes de hardened-sources. Una vez que |
| 312 |
-su sistema esté andando puede usar el modo de aprendizaje de grsecurity para |
| 313 |
-construir las ACLs (Lista de Control de Acceso) para su sistema. |
| 314 |
+Si desea usar grsecurity no tiene de qué preocuparse acerca de las fases |
| 315 |
+ya que no requiere de cambios en el espacio del usuario. Simplemente use |
| 316 |
+las fases pie-ssp y una vez que esté listo para construir el núcleo, use |
| 317 |
+uno que tenga activado grsecurity tal como las fuentes de |
| 318 |
+hardened-sources. Una vez que su sistema esté corriendo puede usar el |
| 319 |
+modo de aprendizaje de grsecurity para construir las ACLs (Lista de |
| 320 |
+Control de Acceso) para su sistema. |
| 321 |
</p> |
| 322 |
|
| 323 |
<p> |
| 324 |
-Similar a grsecurity, RSBAC no requiere de cambio alguno en el espacio del |
| 325 |
-usuario pero puede ser instalado luego de configurar una instalación normal de |
| 326 |
-Gentoo. RSBAC es soportado por el núcleo rsbac-sources. Una vez que su sistema |
| 327 |
-está corriendo puede elegir los distintos modelos de control de acceso ofrecidos |
| 328 |
-por RSBAC pues todos son módulos. La documentación de Gentoo RSBAC lista los |
| 329 |
-varios modelos ofrecidos y provee más información acerca de cada uno de ellos. |
| 330 |
+Similar a grsecurity, RSBAC no requiere de cambio alguno en el espacio |
| 331 |
+del usuario pero puede ser instalado luego de configurar una instalación |
| 332 |
+normal de Gentoo. RSBAC es soportado por el núcleo rsbac-sources. Una |
| 333 |
+vez que su sistema está corriendo puede elegir los distintos modelos de |
| 334 |
+control de acceso ofrecidos por RSBAC pues todos son módulos. La |
| 335 |
+documentación de Gentoo RSBAC lista los varios modelos ofrecidos y |
| 336 |
+ofrece más información acerca de cada uno de ellos. |
| 337 |
</p> |
| 338 |
|
| 339 |
<p> |
| 340 |
@@ -205,18 +224,19 @@ |
| 341 |
intenciones de ofrecer más y lo haremos en el futuro. Ejemplo de capas |
| 342 |
adicionales son detección/prevención de intrusión, que estarán ubicadas |
| 343 |
primero, incluso antes de PaX. Discos y memoria de intercambio cifrados |
| 344 |
-ofrecen protección contra las violaciones de seguridad "física". Auditar le |
| 345 |
-permitiría ver y reaccionar a los riesgos antes de que se conviertan en un |
| 346 |
-compromiso. El tráfico de red cifrado y autenticación fuerte también son capas |
| 347 |
-que son muy bien soportadas en las instalaciones de Linux y probablemente no nos |
| 348 |
-concentraremos en aquello. |
| 349 |
+ofrecen protección contra las violaciones de seguridad "física". Auditar |
| 350 |
+le permitiría ver y reaccionar a los riesgos antes de que se conviertan |
| 351 |
+en un compromiso. El tráfico de red cifrado y autenticación fuerte |
| 352 |
+también son capas que son muy bien soportadas en las instalaciones de |
| 353 |
+Linux y probablemente no nos concentraremos en aquello. |
| 354 |
</p> |
| 355 |
+ |
| 356 |
</body> |
| 357 |
</section> |
| 358 |
</chapter> |
| 359 |
|
| 360 |
<chapter> |
| 361 |
-<title>Recursos</title> |
| 362 |
+<title>Recursos</title> |
| 363 |
<section> |
| 364 |
<body> |
| 365 |
|
| 366 |
@@ -240,7 +260,7 @@ |
| 367 |
<uri>http://pax.grsecurity.net</uri> |
| 368 |
</ti> |
| 369 |
<ti> |
| 370 |
- <uri>http://hardened.gentoo.org/pax-quickstart.xml</uri> |
| 371 |
+ <uri>http://www.gentoo.org/proj/es/hardened/pax-quickstart.xml</uri> |
| 372 |
</ti> |
| 373 |
</tr> |
| 374 |
<tr> |
| 375 |
@@ -273,7 +293,7 @@ |
| 376 |
<uri>http://www.nsa.gov/selinux</uri> |
| 377 |
</ti> |
| 378 |
<ti> |
| 379 |
- <uri>http://hardened.gentoo.org/selinux</uri> |
| 380 |
+ <uri>http://www.gentoo.org/proj/es/hardened/selinux/</uri> |
| 381 |
</ti> |
| 382 |
</tr> |
| 383 |
<tr> |
| 384 |
@@ -284,18 +304,7 @@ |
| 385 |
<uri>http://www.grsecurity.net</uri> |
| 386 |
</ti> |
| 387 |
<ti> |
| 388 |
- <uri>http://hardened.gentoo.org/grsecurity.xml</uri> |
| 389 |
- </ti> |
| 390 |
-</tr> |
| 391 |
-<tr> |
| 392 |
- <ti> |
| 393 |
- RSBAC |
| 394 |
- </ti> |
| 395 |
- <ti> |
| 396 |
- <uri>http://www.rsbac.org</uri> |
| 397 |
- </ti> |
| 398 |
- <ti> |
| 399 |
- <uri>http://hardened.gentoo.org/rsbac</uri> |
| 400 |
+ <uri>http://www.gentoo.org/proj/es/hardened/grsecurity.xml</uri> |
| 401 |
</ti> |
| 402 |
</tr> |
| 403 |
</table> |
Archives