/ 0]-Home-(Español).mediawiki
0]-Home-(Español).mediawiki
1 = Acerca de HardenedBSD = 2 3 HardenedBSD es un fork de FreeBSD, fundado en 2014, que implementa mitigación de exploits y tecnologías de hardening de seguridad. El principal objetivo de HardenedBSD es el de realzar una re-implementación desde cero del set de parches de grsecurity para Linux en HardenedBSD. 4 5 Algunas de las características de HardenedBSD se pueden activar por aplicación o por jaula usando secadm o hbsdcontrol. La documentación para ambas herramientas se cubrirá más adelante. 6 7 Este wiki ha sido portado desde la sección 14 del [https://hardenedbsd.org/content/hardenedbsd-handbook Manual de HardenedBSD]. 8 9 === Historia === 10 11 Los trabajos con HardenedBSD comenzaron en 2013 cuando Oliver Pinter y Shawn Webb empezaron a trabajar en una implementación del Address Space Layout Randomization (ASLR), basado en la documentación disponible públicamente sobre PaX, para FreeBSD. En ese entonces, HardenedBSD se había concebido para ser zona de pruebas para el desarrollo experimental del parche de ASLR. Al pasar del tiempo, y de que el proceso de publicación de ASLR hacia FreeBSD se hacía más complicado, HardenedBSD se convirtió naturalmente en un fork. 12 13 HardenedBSD completó su implementación de ASLR en 2015 con la más sólida forma de ASLR en cualquiera de los BSDs. Desde entonces, HardenedBSD ha seguido implementando otras tecnologías de mitigación de exploits y hardening. OPNsense, un cortafuegos open source basado en FreeBSD, incorporó la implementación ASLR de HardenedBSD en 2016. 14 15 HardenedBSD existe hoy día como un fork de FreeBSD que sigue muy de cerca el código fuente de FreeBSD. HardenedBSD se sincroniza con FreeBSD cada seis horas. Algunas de las ramas, pero no todas, se listan a continuación: 16 17 * HEAD -> hardened/current/master 18 * stable/11 -> hardened/stable/11 19 * releng/11.2 -> hardened/releng/11.2 20 21 === Características === 22 23 HardenedBSD ha implementado exitosamente las siguientes características: 24 25 * ASLR inspirado en PaX 26 * NOEXEC inspirado en PaX 27 * SEGVGUARD inspirado en PaX 28 * Base compilada como Position Independent Executables (PIEs) 29 * Base compilada con full RELRO (RELRO + BIND_NOW) 30 * Hardening de ciertos nodos sysctl sensitivos 31 * Hardening de la pila de red 32 * Reforzamiento de integridad de archivo ejecutable 33 * Hardening del proceso de arranque 34 * Hardening de procs/linprocfs 35 * Trusted Path Execution (TPE) 36 * PIDs Randomizados 37 * SafeStack en la base 38 * SafeStack disponible en los ports 39 * Non-Cross-DSO CFI en la base 40 * Non-Cross-DSO CFI disponible en los ports 41 * Retpoline applicado a la base y ports 42 43 === Opciones Genéricas del Kernel === 44 45 Todas las características del HardenedBSD que dependen de código del requieren la siguiente opción del kernel: 46 47 <code> 48 options PAX 49 </code> 50 51 Adicionalmente, la siguiente opción del kernel no es requerida, pero expone nodos sysctl extra: 52 53 <code> 54 options PAX_SYSCTLS 55 </code> 56 57 Hardening del sistema genérico puede ser habilitado con la siguiente opción del kernel: 58 59 <code> 60 options PAX_HARDENING 61 </code> 62 63 === Hardening del Sistema Genérico === 64 65 HardenedBSD implementa hardening del sistema genérico con la opción del kernel <code>PAX_HARDENING</code>. Muchas de estas características de hardening tratan con la restricción de lo que los usuarios no-root pueden hacer. Cuando el kernel está compilado con el opción del kernel <code>PAX_HARDENING</code>, ciertos nodos <code>sysctl(8)</code> son modificados de sus valores predeterminados. 66 67 <code>procfs(5)</code> y <code>linprocfs(5)</code> se modifican para prevenir escrituras arbitrarias a los registros de un proceso. Este comportamiento es controlado por el nodo <code>sysctl(8)</code> <code>hardening.procfs_harden</code>. 68 69 Las llamadas al sistema relacionadas con <code>kld(4)</code> están restringidas a usuarios no enjaulados y solo-root. Al intentar listar los módulos del kernel usando <code>modfind(2)</code>, <code>kldfind(2)</code>, y otras llamadas al sistema relacionadas con KLD resultarán en permisos denegados si son usados por un usuario no-root o uno enjaulado. 70 71 ==== Nodos sysctl Modificados ==== 72 73 Estos son los nodos que están modificados de sus valores originales cuando <code>PAX_HARDENING</code> está habilitado en el kernel: 74 75 {| class="wikitable" 76 ! Nodo 77 ! Descripción 78 ! Tipo 79 ! Valor Original 80 ! Valor Hardened 81 |- 82 | kern.msgbuf_show_timestamp 83 | Mostrar el timestamp en msgbuf 84 | Entero 85 | 0 86 | 1 87 |- 88 | kern.randompid 89 | Modulo PID Randomizado 90 | Entero 91 | 0, lectura+escritura 92 | Establecido aleatoriamente al arranque y hecho solo-lectura 93 |- 94 | net.inet.ip.random_id 95 | Asigna valores ID aleatorios de IP 96 | Entero 97 | 0 98 | 1 99 |- 100 | net.inet6.ip6.use_deprecated 101 | Permite el uso de direcciones de las cuales sus tiempos de vida preferidos han expirado 102 | Entero 103 | 1 104 | 0 105 |- 106 | net.inet6.ip6.use_tempaddr 107 | Usa direcciones IPv6 temporales con SLAAC 108 | Entero 109 | 0 110 | 1 111 |- 112 | net.inet6.ip6.prefer_tempaddr 113 | Prefiere direcciones IPv6 temporales generadas al final 114 | Entero 115 | 0 116 | 1 117 |- 118 | security.bsd.see_other_gids 119 | Procesos no privilegiados pueden ver sujetos/objetos con diferentes gid reales 120 | Entero 121 | 1 122 | 0 123 |- 124 | security.bsd.see_other_uids 125 | Procesos no privilegiados pueden ver sujetos/objetos con diferentes uid reales 126 | Entero 127 | 1 128 | 0 129 |- 130 | security.bsd.hardlink_check_gid 131 | Procesos no privilegiados no pueden crear hard links a archivos pertenecientes a otros grupos 132 | Entero 133 | 0 134 | 1 135 |- 136 | security.bsd.hardlink_check_uid 137 | Procesos no privilegiados no pueden crear hard links a archivos pertenecientes a otros usuarios 138 | Entero 139 | 0 140 | 1 141 |- 142 | security.bsd.stack_guard_page 143 | Insertar página stack guard adelante de segmentos crecientes 144 | Entero 145 | 0 146 | 1 147 |- 148 | security.bsd.unprivileged_proc_debug 149 | Procesos no privilegiados pueden usar debugging de procesos y servicios de tracing 150 | Entero 151 | 1 152 | 0 153 |- 154 | security.bsd.unprivileged_read_msgbuf 155 | Procesos no privilegiados pueden leer el buffer de mensajes del kernel 156 | Entero 157 | 1 158 | 0 159 |} 160 161 === Aleatoriedad en la disposición del espacio de direcciones (ASLR) === 162 163 ASLR añade aleatoriedad en la disposición del espacio de direcciones virtuales de un proceso mediante el uso de deltas aleatorias. ASLR previene que los atacantes conozcan en qué parte de la memoria se encuentran las vulnerabilidades. Sin ASLR, los atacantes pueden fácilmente desarrollar y reusar exploits a través de todos los sistemas implementados. Como es el caso con todas las tecnologías de mitigación de exploits, ASLR está pensado para ayudar a frustar a los atacantes, aunque ASLR por sí solo no es suficiente para detener completamente los ataques. ASLR simplemente proporciona una base sólida en la cual implementar futuras tecnologías de mitigación de exploits. Un enfoque holístico para la seguridad (denominado, defensa-a-fondo) es la mejor manera de asegurar un sistema. Adicionalmente, ASLR está dirigido y diseñado para ayudar a prevenir ataques remotos exitosos, no locales. 164 165 La implementación ASLR de HardenedBSD está basada en el diseño y documentación de PaX. La documentación de PaX puede ser encontrada [https://git.hardenedbsd.org/hardenedbsd/pax-docs-mirror/-/blob/master/aslr.txt aquí]. 166 167 El 13 de Julio de 2015, la implementacíon ASLR de HardenedBSD se completó con full stack y randomización VDSO. Desde entonces, varias mejoras se han hecho, como la implementación de aleatoriedad en el orden de carga de las librerías compartidas. HardenedBSD es el único BSD que soporta aleatoriedad true stack. Queriendo decir, que la parte alta de la pila está randomizada además de un hueco de tamaño aleatorio entre la parte más alta de la pila y el inicio de la pila del usuario. 168 169 ASLR está habilitado por defecto en la configuración del kernel <code>HARDENEDBSD</code>. 170 ASLR ha sido probado y se sabe que funciona en amd64, i386, arm, arm64, y risc-v. Las opciones para ASLR son: 171 172 <code>options PAX</code><br> 173 <code>options PAX_ASLR</code> 174 175 Si el kernel se ha compilado con <code>options PAX_SYSCTLS</code>, entonces el nodo sysctl <code>hardening.pax.aslr.status</code> estará disponible. Los siguientes valores determinarán el reforzamiento de ASLR: 176 177 * 0 - Reforzamiento deshabilitado 178 * 1 - Deshabilitado por defecto. El usuario debe incluir las aplicaciones. 179 * 2 - Habilitado por defecto. El usuario debe excluir las aplicaciones. (predeterminado) 180 * 3 - Reforzamiento habilitado 181 182 ==== Implementación ==== 183 184 El ASLR de HardenedBSD usa un set de cuatro deltas en sistemas de 32-bits y cinco deltas en sistemas de 64-bits. Adicionalmente, en sistemas de 64-bits, la compatibilidad 32-bits está soportada por un set de deltas diferentes. Los deltas son calculados al momento de la activación de imágen (execve). Los deltas están proporcionados como un rastro para el subsistema de memoria virtual, el cual después podría modificar el rastro. Sería el caso cuando la aplicación explícitamente solicita soporte de superpágina u otras restricciones de alineamiento. 185 186 Los deltas son: 187 188 * Base de ejecución PIE 189 * Rastro mmap para mappings no-fijos 190 * Parte alta de la pila y hueco 191 * Virtual Dynamic Shared Object (VDSO) 192 * En sistemas de 64-bits, rastro mmap para mappings <code>MAP_32BIT</code> 193 194 El cálculo de cada delta está controlado por cuántos bits de entropía el usuario quiere introducir en dicho delta. La cantidad de entropía se puede anular en la configuración del kernel y a través de las opciones al momento del arranque (<code>loader.conf(5)</code>). Por defecto, HardenedBSD usa la siguiente cantidad de entropía: 195 196 {| class="wikitable" 197 ! Delta 198 ! 32-bits 199 ! 64-bits 200 ! Compatibilidad 201 ! Opción 202 ! Opción de Compatibilidad 203 ! Opción del Kernel 204 ! Opción de Compatibiliad del Kernel 205 |- 206 | mmap 207 | 14 bits 208 | 30 bits 209 | 14 bits 210 | hardening.pax.aslr.mmap_len 211 | hardening.pax.aslr.compat.mmap_len 212 | PAX_ASLR_DELTA_MMAP_DEF_LEN 213 | PAX_ASLR_COMPAT_DELTA_MMAP_DEF_LEN 214 |- 215 | Stack 216 | 14 bits 217 | 42 bits 218 | 14 bits 219 | hardening.pax.aslr.stack_len 220 | hardening.pax.aslr.compat.stack_len 221 | PAX_ASLR_DELTA_STACK_DEF_LEN 222 | PAX_ASLR_COMPAT_DELTA_STACK_DEF_LEN 223 |- 224 | PIE exec base 225 | 14 bits 226 | 30 bits 227 | 14 bits 228 | hardening.pax.aslr.exec_len 229 | hardening.pax.aslr.compat.exec_len 230 | PAX_ASLR_DELTA_EXEC_DEF_LEN 231 | PAX_ASLR_COMPAT_DELTA_EXEC_DEF_LEN 232 |- 233 | VDSO 234 | 8 bits 235 | 28 bits 236 | 8 bits 237 | hardening.pax.aslr.vdso_len 238 | hardening.pax.aslr.compat.vdso_len 239 | PAX_ASLR_DELTA_VDSO_DEF_LEN 240 | PAX_ASLR_COMPAT_DELTA_VDSO_DEF_LEN 241 |- 242 | MAP_32BIT 243 | N/A 244 | 18 bits 245 | N/A 246 | hardening.pax.aslr.map32bit_len 247 | N/A 248 | PAX_ASLR_DELTA_MAP32BIT_DEF_LEN 249 | N/A 250 |} 251 252 Cuando un proceso se bifurca, el proceso hijo hereda las configuraciones ASLR del padre, incluyendo los deltas. Solo al momento de la activación de imágen (execve) el proceso reibe nuevos deltas. 253 254 ==== Position-Independent Executables (PIEs) ==== 255 256 Para hacer un uso completo de ASLR, las aplicaciones deben ser compiladas como Position-Independent Executables (PIEs). Si una aplicación no se compila como PIE, entonces ASLR será aplicado a todo menos la base de ejecución. Toda la base está compilada como PIE, con excepción de algunas aplicaciones que explícitamente requieren ser compiladas estáticamente. Esas aplicaciones son: 257 258 * Todas las aplicaciones en /rescue 259 * /sbin/devd 260 * /sbin/init 261 * /usr/sbin/nologin 262 263 Compilar toda la base como PIE se puede deshabilitar poniendo <code>WITHOUT_PIE</code> en <code>src.conf(5)</code>. 264 265 ==== Aleatoriedad en el Orden de Carga de las Librerías Compartidas ==== 266 267 Romper ASLR de forma remota requiere encadenar multiples vulnerabilidades, incluyendo una o más vulnerabilidades de filtración de información. Las vulnerabilidades de filtración de información exponen datos que un atacante puede usar para determinar el diseño de la memoria de un proceso. Ataques de reuso de código, como ROP y sus variantes, existen para brincarse mitigaciones de exploits como PAGEEXEC/NOEXEC. A través de los años, muchas utilerías para generación de gadget ROP automatizados se han desarrollado. Las utilerías generalmente dependen de gadgets encontrados via librerías compartidas y requieren que esas librerías compartidas sean cargadas en el mismo orden. Randominzando el orden en el que las librerías compartidas se cargan, los gadgets ROP tienen una mayor probabilidad de fallar. La carga aleatoria de las librerías compartidas está deshabilitada por defecto, pero puede habilitarse por aplicación usando secadm o hbsdcontrol. 268 269 === PaX SEGVGUARD === 270 271 ASLR tiene debilidades conocidas. Si hay una fuga de información, los atacantes pueden usar la fuga para determinar el diseño de la memoria y, con el tiempo, explotar con éxito la aplicación. 272 273 Algunas aplicaciones, como los demonios, pueden configurarse opcionalmente para reiniciarse automáticamente después de una falla. Reiniciar automáticamente las aplicaciones puede suponer un riesgo para la seguridad al permitir que los atacantes repitan los ataques fallidos, modificando el ataque hasta que tenga éxito. 274 275 PaX SEGVGUARD proporciona una mitigación para tales casos. SEGVGUARD realiza un seguimiento de cuántas veces se ha bloqueado una aplicación determinada dentro de una ventana configurable y suspenderá la ejecución de la aplicación durante un tiempo configurable una vez que se haya alcanzado el límite de bloqueo. 276 277 La opción del kernel para PaX SEGVGUARD es: 278 279 <code>options PAX_SEGVGUARD</code> 280 281 Debido a problemas de rendimiento, SEGVGUARD está configurado para habilitarse de forma predeterminada. SEGVGUARD se puede configurar para que se desactive configurando el nodo sysctl <code>hardening.pax.segvguard.status</code> a 2. 282 283 === PAGEEXEC and MPROTECT (alias, NOEXEC)=== 284 285 [https://git.hardenedbsd.org/hardenedbsd/pax-docs-mirror/-/blob/master/pageexec.txt PAGEEXEC] y [https://git.hardenedbsd.org/hardenedbsd/pax-docs-mirror/-/blob/master/mprotect.txt MPROTECT] componen lo que se conoce comúnmente como W^X (W xor X). EL diseño e implementación en HardenedBSD está inspirado por el de PaX. PAGEEXEC previene a las aplicaciones de crear mapeos de memoria que son a la vez de escritura (W) y ejecución (X) al momento de hacer <code>mmap(2)</code>. MPROTECT previene que las aplicaciones cambien los mapeos de memoria entre escritura y ejecución con <code>mprotect(2)</code>. Combinando los dos PAGEEXEC y MPROTECT se previene que los atacantes ejecuten inyecciones de código, forzando a los atacantes a utilizar técnicas de reuso de código como ROP y sus variantes. Las técnicas de reuso de código son muy difíciles para que sean efectivas, especialmente cuando se presentan y están activas múltiples tecnologías de mitigación de exploits. 286 287 Las caracterísiticas de PAGEEXEC y MPROTECT pueden ser habilitadas con la opción del kernel <code>PAX_NOEXEC</code> y está habilitada por defecto en el kernel <code>HARDENEDBSD</code>. Si también está habilitada la opción </code>PAX_SYSCTLS</code>, dos nuevos nodos sysctl serán creados, y siguen la misma semántica que los sysctl <code>hardening.pax.aslr.status</code>: 288 289 * <code>hardening.pax.pageexec.status</code> - Default 2 290 * <code>hardening.pax.mprotect.status</code> - Default 2 291 292 ==== PAGEEXEC ==== 293 294 Si una aplicación requiere de un mapeo de memoria <code>mmap(2)</code>, y la aplicación requiere de <code>PROT_WRITE</code> and <code>PROT_EXEC</code>, entonces <code>PROT_EXEC</code> es eliminado. La aplicación será capaz de escribir al mapeo, pero no será capaz de ejecutar lo que fue escrito. Cuando una aplicación requiere mapeos W|X, la aplicación es más común que escriba al mapeo, pero no ejecutarlo. Ese es el caso con algunos scripts de Python: el desarrollador simplemente pide más permisos de los que realmente son necesarios. 295 296 El kernel mantiene un concepto de protección pax. HardenedBSD elimina <code>PROT_EXEC</code> de la protección max cuando se pide <code>PROT_WRITE</code>. Cuando <code>PROT_EXEC</code> es requerido, se elimina <code>PROT_WRITE</code> de la protección max. Cuando las dos son requeridas, a <code>PROT_WRITE</code> se le da prioridad y se elimina <code>PROT_EXEC</code> de ambas protecciones, requerida y max. 297 298 ==== MPROTECT ==== 299 300 Si una aplicación solicita que se cambie una asignación de escritura a ejecutable a través de <code>mprotect (2)</code>, la solicitud fallará y establecerá <code>errno</code> en <code>EPERM</code>. Lo mismo se aplica a un mapeo ejecutable que se cambia a escritura a través de <code>mprotect (2)</code>. Aplicaciones y objetos compartidos que utilicen reubicaciones de texto (TEXTREL) tienen problemas con la característica MPROTECT. Los TEXTREL requieren que el código ejecutable se reubique a diferentes lugares en la memoria. Durante el proceso de relocación, la memoria recién asignada debe ser de escritura y ejecutable. Una vez que el proceso de relocación ha finalizado, la asignación se puede marcar como <code>PROT_READ | PROT_EXEC</code>. 301 302 Algunas aplicaciones con un JIT, especialmente Firefox, optan por crear asignaciones de memoria que no son ejecutables, pero que actualizan el mapeo a ejecutable cuando es apropiado. Esto elimina el problema de tener asignaciones activas de memoria que sean de escritura y ejecución. Esto hace que aplicaciones como Firefox funcionen con PAGEEXEC, pero que todavía tienen problemas con MPROTECT. 303 304 Al combinar PAGEEXEC y MPROTECT, HardenedBSD permite una forma estricta de W^X. Algunas aplicaciones pueden tener problemas con PAGEEXEC, MPROTECT, o ambos. Cuando surgen problemas, pueden utilizarse secadm o hbsdcontrol para deshabilitar PAGEEXEC, MPROTECT, o ambos solo para esa aplicación. 305 306 === SafeStack === 307 308 SafeStack es una mitigación de exploit que crea dos pilas: una para los datos que deben estar seguros, como las direcciones de retorno y punteros a la función y una pila insegura para todo lo demás. SafeStack promete una penalización de bajo rendimiento (normalmente alrededor del 0,1%). 309 310 SafeStack requiere tanto de ASLR como de W^X para ser efectivo. Con HardenedBSD satisfaciendo ambos pre-requisitos, SafeStack fue considerado un excelente candidato para la inclusión por defecto en HardenedBSD. A partir de HardenedBSD 11-STABLE, está habilitado por defecto para amd64. SafeStack se puede desactivar configurando <code>WITHOUT_SAFESTACK</code> en <code>src.conf (5)</code>. 311 312 A partir del 8 de octubre de 2018, SafeStack solo admite ser aplicado en aplicaciones y bibliotecas no compartidas. Múltiples parches han sido enviados a clang por terceros para agregar el soporte para la biblioteca compartida faltante. Como tal, SafeStack todavía está en desarrollo activo. 313 314 SafeStack también se ha puesto a disposición en el árbol de puertos HardenedBSD. A diferencia de PIE, RELRO y BIND_NOW, no está habilitado globalmente para el árbol de puertos. Algunos puertos que se sabe que funcionan bien con SafeStack lo tienen habilitado por defecto. Los usuarios pueden alternar SafeStack usando el target <code>config</code> en make. Además, la opción SafeStack es aplicable solamente a la arquitectura amd64. Intentar habilitar SafeStack para una compilación de puerto no-amd64 resultará en un NO-OP. SafeStack simplemente no se aplicará. 315 316 === Control-Flow Integrity (CFI) === 317 318 La integridad de control-flujo (CFI) es una técnica de mitigación de exploit que evita la transferencia no deseada de control desde las instrucciones de la rama a ubicaciones de memoria válidas arbitrarias. La implementación de CFI de clang/llvm viene en dos formas: Cross-DSO CFI y non-Cross-DSO CFI. HardenedBSD 12 habilita non-Cross-DSO CFI de forma predeterminada en amd64 y arm64 para la base. 319 320 CFI requiere un enlazador que admita la optimización de tiempo de enlace (LTO). A partir de 12, HardenedBSD viene con ld.lld como el enlazador predeterminado. ld.lld soporta LTO. 321 322 El Non-Cross-DSO CFI agrega chequeos antes y después de cada instrucción de la rama en la propia aplicación. Si una aplicación carga bibliotecas a través de <code>dlopen (3)</code> y resuelve funciones a través de <code>dlsym (3)</code> y llama a esas funciones, la aplicación abortará. Algunas aplicaciones, como <code>bhyveload (8)</code> hacen esto y así tienen el esquema cfi-icall deshabilitado, lo que le permite llamar a funciones resueltas vía <code>dlsym (3)</code>. Así, si un usuario encuentra que una aplicación falla en HardenedBSD 12, el usuario debe presentar un informe de error. El esquema de cfi-icall puede ser deshabilitado al crear <code>world</code> agregando una anulación de CFI en el Makefile de esa aplicación. 323 324 Tenga en cuenta que Non-Cross-DSO CFI no requiere ASLR y W^X estricto. Dado que Cross-DSO CFI mantiene metadatos e información de estado, Cross-DSO CFI requiere ASLR y W^X para ser efectivo. 325 326 Se ha agregado soporte Non-Cross-DSO CFI a la infraestructura de puertos de HardenedBSD. Sin embargo, no está habilitado por defecto. Soporte para CFI en los puertos sigue siendo muy prematuros y solo está disponible para esos usuarios valientes que quieran experimentar. 327 328 A partir del 20 de mayo de 2017, Cross-DSO CFI se está investigando activamente. Sin embargo, el soporte para Cross-DSO CFI no está disponible en HardenedBSD, todavía. Cross-DSO CFI permitiría funciones resueltas a través de <code>dlopen (3) / dlsym (3)</code> para trabajar ya que CFI podría aplicarse entre límites de objetos compartidos dinámicos (DSO). Progreso significativo se ha realizado en el primer semestre de 2018 con respecto a Cross-DSO CFI. El sistema operativo base puede compilarse completamente con Cross-DSO CFI. El 16 de julio de 2018, un [https://hardenedbsd.org/article/shawn-webb/2018-07-16/preliminary-call-testing-cross-dso-cfi Call For Testing] pre-alfa fue lanzado para una prueba inicial más amplia. El equipo de desarrollo de HardenedBSD espera lanzar Cross-DSO CFI en la base dentro de la segunda mitad de 2019. 329 330 === hbsdcontrol === 331 332 hbsdcontrol (8) es una herramienta, incluida en la base, que permite a los usuarios alternar las mitigaciones de exploits por aplicación. Los usuarios normalmente usarán hbsdcontrol para deshabilitar las restricciones de PAGEEXEC y/o MPROTECT. hbsdcontrol tiene un alcance similar al de secadm y se prefiere a secadm para sistemas de archivos que admiten atributos extendidos. 333 334 A diferencia de secadm, hbsdcontrol no usa un archivo de configuración. En su lugar, almacena metadatos en los atributos extendidos del sistema de archivos. Tanto UFS como ZFS soportan atributos extendidos. Los sistemas de archivos basados en red, como NFS o SMB/CIFS no lo hacen. secadm es el método preferido para la mitigación de expliots que se activa solo en los casos en que no se admiten los atributos extendidos. 335 336 Ejemplo de uso de hbsdcontrol para deshabilitar MPROTECT para Firefox: 337 338 <code># hbsdcontrol pax disable mprotect /usr/local/lib/firefox/firefox</code><br> 339 <code># hbsdcontrol pax disable mprotect /usr/local/lib/firefox/plugin-container</code> 340 341 === Security Administration (secadm) === 342 343 Secadm es una herramienta, distribuida a través de los puertos, que permite a los usuarios alternar las mitigaciones de exploits por aplicación y por jaula. Los usuarios normalmente usan secadm para deshabilitar las restricciones PAGEEXEC y/o MPROTECT. 344 345 secadm también incluye una característica conocida como Integriforce. Integriforce es una implementación de ejecución verificada. Refuerza las firmas basadas en hash para binarios y sus objetos compartidos dependientes. Integriforce se puede establecer en modo de whitelisting. Cuando hay al menos una regla de Integriforce habilitada, todas las aplicaciones 346 deseadas y sus objetos compartidos dependientes también deben tener reglas. Si una aplicación y sus objetos compartidos no están incluidos en el conjunto de reglas, se rechazará la ejecución de esa aplicación. Esto también afecta a los objetos compartidos cargados a través de [https://www.freebsd.org/cgi/man.cgi?query=dlopen&sektion=3&manpath=freebsd-release-ports dlopen (3)]. 347 348 Cuando se agrega un archivo al conjunto de reglas de secadm, secadm no permitirá modificaciones a ese archivo. Esto incluye eliminar, agregar, truncar o modificar el archivo. Esto se debe a que secadm realiza un seguimiento de los archivos bajo su control utilizando el inodo. La modificación del archivo puede cambiar el inodo, o liberarlo en caso de eliminación, por lo que se modifica implícitamente el conjunto de reglas de secadm. Para proteger la integridad del conjunto de reglas cargado, secadm también protege los archivos que controla. 349 350 Por lo tanto, al actualizar los puertos o paquetes instalados, se debe tener cuidado. Limpie el conjunto de reglas antes de instalar actualizaciones. El conjunto de reglas se puede volver a cargar después de la actualización. 351 352 ==== Descargando e Instalando secadm ==== 353 354 secadm no es actualmente parte de la base, aunque eso está planeado para el futuro próximo. secadm puede ser instalado ya sea mediante el repositorio de paquetes: 355 356 <code># pkg install secadm-kmod secadm</code> 357 358 o usando el árbol de puertos de HardenedBSD: 359 360 <code># cd /usr/ports/hardenedbsd/secadm</code><br> 361 <code># make install clean</code><br> 362 <code># cd /usr/ports/hardenedbsd/secadm-kmod</code><br> 363 <code># make install clean</code> 364 365 ==== Configurando secadm ==== 366 367 De forma predeterminada, secadm busca un archivo de configuración en <code>/usr/local/etc/secadm.rules</code>. Para los propósitos de esta documentación, ese archivo simplemente será referenciado como <code>secadm.rules</code>. secadm no instala ni administra el archivo <code>secadm.rules</code>. Simplemente lee el archivo, si existe, pasando los datos analizados al módulo del kernel. secadm se puede configurar a través de la línea de comandos o <code>secadm.rules</code>. Tanto secadm como <code>secadm.rules</code> contienen páginas del manual. Una vez instalado, los usuarios pueden ver la página del manual de secadm en la sección 8 y secadm.rules en la sección 5. 368 369 <code>secadm.rules</code> debe estar en un formato que libucl pueda analizar, ya que secadm usa libucl para analizar <code>secadm.rules</code>. 370 371 Un ejemplo de <code>secadm.rules</code> se vería así: 372 373 <code>secadm {</code><br> 374 <code> pax {</code><br> 375 <code> path: "/usr/local/lib/firefox/firefox",</code><br> 376 <code> mprotect: false,</code><br> 377 <code> },</code><br> 378 <code> pax {</code><br> 379 <code> path: "/usr/local/lib/firefox/plugin-container",</code><br> 380 <code> mprotect: false,</code><br> 381 <code> },</code><br> 382 <code>}</code> 383 384 Una vez que secadm se ha configurado, puede ser iniciado mediante el sistema [https://www.freebsd.org/cgi/man.cgi?query=rc&sektion=8&manpath=freebsd-release-ports rc(8)]: 385 386 <code># sysrc secadm_enable=YES</code><br> 387 <code># service secadm start</code> 388 389 ==== Todas las opciones de configuración de secadm ==== 390 391 Estas son las opciones pax disponibles: 392 393 {| class="wikitable" 394 !Opción 395 !Requerimiento 396 !Tipo 397 !Descripción 398 |- 399 | path 400 | Requerido 401 | String 402 | Ruta completa del ejecutable 403 |- 404 | aslr 405 | Opcional 406 | Boolean 407 | Alternar ASLR 408 |- 409 | disallow_map32bit 410 | Opcional 411 | Boolean 412 | Alternar la habilidad de usar la bandera MAP_32BIT [https://www.freebsd.org/cgi/man.cgi?query=mmap&sektion=2&manpath=freebsd-release-ports mmap(2)] en sistemas de 64-bit 413 |- 414 | mprotect 415 | Opcional 416 | Boolean 417 | Alternar las restricciones mprotect 418 |- 419 | pageexec 420 | Opcional 421 | Boolean 422 | Alternar las restricciones pageexec 423 |- 424 | segvguard 425 | Opcional 426 | Boolean 427 | Alternar SEGVGUARD 428 |- 429 | shlibrandom 430 | Opcional 431 | Boolean 432 | Alternar la aleatoriedad del órden de carga de la librería compartida 433 |} 434 435 Ejemplo de configuración pax: 436 437 <code>secadm {</code><br> 438 <code> pax {</code><br> 439 <code> path: "/usr/local/lib/firefox/firefox",</code><br> 440 <code> mprotect: false,</code><br> 441 <code> },</code><br> 442 <code> pax {</code><br> 443 <code> path: "/usr/local/lib/firefox/plugin-container",</code><br> 444 <code> mprotect: false,</code><br> 445 <code> },</code><br> 446 <code>}</code><br> 447 </code> 448 449 Estas son las opciones de integriforce disponibles: 450 451 {| class="wikitable" 452 ! Opción 453 ! Requerimiento 454 ! Tipo 455 ! Descripción 456 |- 457 | path 458 | Requerido 459 | String 460 | Ruta completa al ejecutable o a la librería compartida 461 |- 462 | hash 463 | Requerido 464 | String 465 | Firma [https://www.freebsd.org/cgi/man.cgi?query=sha1&sektion=1&manpath=freebsd-release-ports sha1(1)] o [https://www.freebsd.org/cgi/man.cgi?query=sha256&sektion=1&manpath=freebsd-release-ports sha256(1)] del archivo 466 |- 467 | type 468 | Requerido 469 | String 470 | Tipo de firma. Ya sea "sha1" o "sha256". 471 |- 472 | mode 473 | Requerido 474 | String 475 | Ya sea "soft" o "hard". En modo soft, si la firma no coincide, una advertencia se escribe en syslog y se permite la ejecución. En modo hard, si la firma no coincide, un error se escribe en syslog y la ejecución se cancela. 476 |} 477 478 Ejemplo de configuración de integriforce: 479 480 <code>secadm {</code><br> 481 <code> integriforce {</code><br> 482 <code> path: "/bin/ls",</code><br> 483 <code> hash: "7dee472b6138d05b3abcd5ea708ce33c8e85b3aac13df350e5d2b52382c20e77",</code><br> 484 <code> type: "sha256",</code><br> 485 <code> mode: "hard",</code><br> 486 <code> }</code><br> 487 <code>}</code> 488 489 === Contribuyendo a HardenedBSD === 490 491 HardenedBSD usa GitLab para el control de las fuentes e informes de errores. Los usuarios pueden enviar informes de errores para el código fuente base de HardenedBSD [https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues aquí] y para los puertos [https://git.hardenedbsd.org/hardenedbsd/ports/-/issues aquí]. Al enviar informes de errores, por favor incluya la siguiente información: 492 493 * Versión de HardenedBSD 494 * Arquitectura 495 * Si el informe se refiere a un kernel panic, el backtrace del panic 496 * Pasos para reproducir el error. 497 498 ==== Proceso de Desarrollo de HardenedBSD ==== 499 500 HardenedBSD usa tres repositorios durante el proceso de desarrollo: 501 502 {| class="wikitable" 503 !Repositorio 504 !Propósito 505 |- 506 | [https://git.hardenedbsd.org/hardenedbsd/HardenedBSD hardened/current/master] 507 | Repositorio Maestro de Desarrollo 508 |- 509 | [https://git.hardenedbsd.org/hardenedbsd/HardenedBSD hardened/XX-stable/master] 510 | Repositorio Estable 511 |} 512 513 Ramas de desarrollo de HardenedBSD: 514 515 {| class="wikitable" 516 !Rama 517 !Repositorio 518 !Actualizaciones Binarias 519 !Propósito 520 |- 521 | hardened/current/master 522 | HardenedBSD 523 | amd64, arm64 524 | Rama maestra de desarrollo (13-CURRENT) 525 |- 526 | hardened/11-stable/master 527 | HardenedBSD 528 | amd64 529 | Desarrollo 11-STABLE 530 |- 531 | hardened/10-stable/master 532 | HardenedBSD 533 | amd64 534 | Desarrollo 10-STABLE 535 |- 536 | hardened/current/drm-next 537 | HardenedBSD-Playground 538 | amd64 539 | HardenedBSD 13-CURRENT con drm-next 540 |- 541 | hardened/current/safestack-arm64 542 | HardenedBSD-Playground 543 | arm64 544 | HardenedBSD 13-CURRENT con SafeStack portado a arm64 545 |- 546 | hardened/current/cross-dso-cfi 547 | HardenedBSD-Playground 548 | N/A 549 | HardenedBSD 13-CURRENT con soporte para Cross-DSO-CFI 550 |} 551 552 === Actualizando HardenedBSD === 553 554 HardenedBSD no usa [https://www.freebsd.org/cgi/man.cgi?query=freebsd-update&sektion=8&manpath=freebsd-release-ports freebsd-update (8)]. En su lugar, HardenedBSD usa una utilidad conocida como hbsd-update. hbsd-update no usa deltas para publicar actualizaciones, sino que distribuye el sistema operativo base en su totalidad. El utilizar deltas implica una sobrecarga de ancho de banda, pero es más fácil de mantener y duplicar. hbsd-update se basa en registros TXT firmados por DNSSEC para distribuir información de versión. 555 556 Las actualizaciones para las ramas estables mantenidas (12-STABLE, 11-STABLE) provienen del repositorio HardenedBSD-STABLE. Las actualizaciones para CURRENT (hardened/current/master) provienen del repositorio de HardenedBSD. 557 558 hbsd-update se configura a través de un archivo de configuración ubicado en <code>/etc/hbsd-update.conf</code>. hbsd-update funciona en un nivel de bifurcación, lo que significa que rastrea las ramas dentro del árbol de origen de HardenedBSD. Por lo tanto, la actualización de una versión principal a otra requiere cambiar las variables dnsrec y branch en <code>hbsd-update.conf</code>. Por ejemplo, el <code>hbsd-update.conf</code> para la rama hardened/current/master en el repositorio de HardenedBSD: 559 560 <code>dnsrec="$(uname -m).master.current.hardened.hardenedbsd.updates.hardenedbsd.org"</code><br> 561 <code>capath="/usr/share/keys/hbsd-update/trusted"</code><br> 562 <code>branch="hardened/current/master"</code><br> 563 <code>baseurl="http://updates.hardenedbsd.org/pub/HardenedBSD/updates/${branch}/$(uname -m)"</code><br> 564 </code> 565 566 Y como otro ejemplo, el archivo <code>hbsd-update.conf</code> para la rama hardened/11-stable/master en el repositorio de HardenedBSD: 567 568 <code>dnsrec="$(uname -m).master.11-stable.hardened.hardenedbsd.updates.hardenedbsd.org"</code><br> 569 <code>capath="/usr/share/keys/hbsd-update/trusted"</code><br> 570 <code>branch="hardened/11-stable/master"</code><br> 571 <code>baseurl="http://updates.hardenedbsd.org/pub/HardenedBSD/updates/${branch}/$(uname -m)"</code><br> 572 </code> 573 574 Entonces, generar un diff entre dos archivos de configuración dará como resultado: 575 576 <code>--- hbsd-update_current.conf 2017-07-21 20:08:22.153616000 -0400</code><br> 577 <code>+++ hbsd-update_11-stable.conf 2017-07-21 20:08:38.003508000 -0400</code><br> 578 <code>@@ -1,4 +1,4 @@</code><br> 579 <code>-dnsrec="$(uname -m).master.current.hardened.hardenedbsd.updates.hardenedbsd.org"</code><br> 580 <code>+dnsrec="$(uname -m).master.11-stable.hardened.hardenedbsd.updates.hardenedbsd.org"</code><br> 581 <code> capath="/usr/share/keys/hbsd-update/trusted"</code><br> 582 <code>-branch="hardened/current/master"</code><br> 583 <code>+branch="hardened/11-stable/master"</code><br> 584 <code>baseurl="http://updates.hardenedbsd.org/pub/HardenedBSD/updates/${branch}/$(uname -m)"</code>