{"id":170830,"date":"2026-05-16T18:24:39","date_gmt":"2026-05-16T16:24:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux"},"modified":"2026-05-16T18:24:39","modified_gmt":"2026-05-16T16:24:39","slug":"model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Modelo de amenazas y caracter\u00edsticas de la evaluaci\u00f3n de vulnerabilidades en el n\u00facleo de Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds ha incorporado al n\u00facleo un documento que regula el proceso de manejo de errores relacionados con la seguridad, define el modelo de amenazas, explica qu\u00e9 errores en el n\u00facleo se consideran vulnerabilidades y aborda las acciones relacionadas con los errores identificados mediante IA. El documento fue preparado por Willy Tarreau, autor de HAProxy y desarrollador veterano del n\u00facleo de Linux, responsable del mantenimiento de varias ramas estables del n\u00facleo. Las bases se fundamentan en los acuerdos alcanzados durante la discusi\u00f3n de vulnerabilidades cr\u00edticas recientemente descubiertas en el n\u00facleo (1, 2, 3, 4), reveladas antes de la publicaci\u00f3n de correcciones y para las cuales, gracias a la IA, se han podido crear exploits funcionales de inmediato. <\/p>\n
Se prescribe tratar la mayor parte de los errores relacionados con la seguridad de forma p\u00fablica, con el fin de atraer a la audiencia m\u00e1s amplia posible y encontrar la soluci\u00f3n \u00f3ptima. Solo se sugiere enviar a una lista de correo privada mensajes urgentes sobre vulnerabilidades de f\u00e1cil explotaci\u00f3n que representen una amenaza para muchos usuarios y que puedan proporcionar privilegios ampliados o capacidades. <\/p>\n
Las vulnerabilidades identificadas mediante asistentes de IA siempre se deben discutir p\u00fablicamente, ya que estos problemas a menudo son detectados simult\u00e1neamente por varios investigadores. No obstante, no es necesario revelar el exploit en el informe; basta con mencionar que est\u00e1 disponible y transmitirlo de forma privada en respuesta a una solicitud del responsable. <\/p>\n
Se describen por separado las reglas para la presentaci\u00f3n de informes generados con la ayuda de asistentes de IA. Se env\u00edan muchos de estos informes y, gracias a ellos, a veces se logran identificar errores en partes del c\u00f3digo mal revisadas, pero los responsables a menudo los ignoran debido a su baja calidad e imprecisiones. Los principales requisitos para los informes generados con la participaci\u00f3n de IA son: <\/p>\n
\n
Concisi\u00f3n, sin relleno y con la esencia y detalles importantes al principio.\n
Texto plano sin etiquetas Markdown ni decoraciones.\n
La comprensi\u00f3n del modelo de amenazas y la especificaci\u00f3n de hechos verificables (por ejemplo, \u00abel error permite que cualquier usuario obtenga CAP_NET_ADMIN\u00bb), en lugar de especulaciones te\u00f3ricas y conjeturas sobre las consecuencias de la vulnerabilidad.\n
Antes de enviar el informe, es imprescindible probar a fondo la funcionalidad del exploit generado a trav\u00e9s de AI y asegurarse de poder reproducir el problema.\n
Utilizar AI para el desarrollo y la prueba de la correcci\u00f3n del problema detectado. <\/ul>\n
Seg\u00fan las estad\u00edsticas de quienes dan soporte, la mayor\u00eda de los informes de errores enviados como correcciones de vulnerabilidades, en realidad no lo son y deben ser tratados en t\u00e9rminos generales como errores normales. Para distinguir entre vulnerabilidades y errores comunes, se ha descrito un modelo de amenazas en el n\u00facleo de Linux. Entre las posibilidades y garant\u00edas cuya violaci\u00f3n puede ser considerada como vulnerabilidad est\u00e1n: <\/p>\n
\n
Aislamiento a nivel de usuario: acceso a archivos solo para el propietario, la memoria del proceso no es accesible para otros usuarios, ptrace est\u00e1 prohibido para procesos ajenos, aislamiento de comunicaciones IPC y de red.\n
Protecci\u00f3n basada en capacidades: sin CAP_SYS_ADMIN no se puede cambiar la configuraci\u00f3n del n\u00facleo, la memoria, el estado del sistema; sin CAP_NET_ADMIN no se pueden cambiar las configuraciones de red ni interceptar el tr\u00e1fico; sin CAP_SYS_PTRACE no se pueden rastrear procesos de otros usuarios.\n
El espacio de nombres de identificadores de usuario (CONFIG_USER_NS) permite a los usuarios no privilegiados crear sus entornos aislados, de los cuales no pueden influir en el espacio de nombres global, por ejemplo, cambiando la hora, cargando m\u00f3dulos y montando dispositivos de bloque.\n
Las interfaces de depuraci\u00f3n (\/proc\/kmsg, perf, debugfs), a trav\u00e9s de las cuales se puede acceder a informaci\u00f3n confidencial, solo est\u00e1n disponibles tras la concesi\u00f3n expl\u00edcita de acceso por parte del administrador. <\/ul>\n
Las capacidades que no se consideran vulnerabilidades: <\/p>\n
\n
Uso de ramas de n\u00facleo obsoletas.\n
Compilaci\u00f3n con opciones habilitadas para desarrolladores o que disminuyen la seguridad (por ejemplo, CONFIG_NOMMU).\n
Establecimiento de configuraciones inseguras en sysctl, opciones de l\u00ednea de comandos, permisos de acceso en el sistema de archivos, capacidades o apertura de acceso a interfaces privilegiadas para usuarios no privilegiados (por ejemplo, acceso de escritura en procfs y debugfs).\n
Problemas en funciones dise\u00f1adas \u00fanicamente para el desarrollo y la depuraci\u00f3n del n\u00facleo, como LOCKDEP, KASAN y FAULT_INJECTION, que no est\u00e1n destinados a incluirse en configuraciones en producci\u00f3n.\n
Problemas en los controladores, m\u00f3dulos y subsistemas situados en la secci\u00f3n STAGING o marcados como experimentales, inseguros o inoperativos.\n
Uso de m\u00f3dulos de n\u00facleo de terceros o forks no oficiales del n\u00facleo.\n
Requisitos de privilegios excesivos, como la necesidad de realizar acciones con derechos de root o de un usuario con derechos CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO y CAP_SYS_MODULE.\n
Ataques te\u00f3ricos que requieren condiciones de laboratorio, miles de millones de intentos, emulaci\u00f3n o modificaci\u00f3n de hardware, costos desproporcionados y configuraciones poco realistas (como sistemas con decenas de miles de n\u00facleos de CPU).\n
Evasi\u00f3n de mecanismos de protecci\u00f3n (por ejemplo, ASLR) sin demostrar un exploit. Ausencia de comprobaciones de argumentos y c\u00f3digos de retorno de errores que no tengan consecuencias evidentes.\n
Fugas de informaci\u00f3n aleatorias, incontrolables para los atacantes, como datos residuales en mensajes de error y fugas de direcciones\/punteros de memoria del n\u00facleo sin una posibilidad de explotaci\u00f3n directa.\n
Errores al montar im\u00e1genes de disco da\u00f1adas, si el controlador no est\u00e1 declarado como apto para su uso con medios no confiables. Problemas con im\u00e1genes de disco que se identifican y solucionan mediante la ejecuci\u00f3n de la utilidad fsck.\n
Ataques que requieren acceso f\u00edsico al hardware, modificaci\u00f3n del hardware o conexi\u00f3n de dispositivos de hardware, como placas para ataques DMA y analizadores l\u00f3gicos, a menos que el sistema est\u00e9 espec\u00edficamente configurado para protegerse contra dichos ataques (IOMMU).\n
Regresiones en funcionalidad y rendimiento que pueden solucionarse ajustando permisos y l\u00edmites. <\/ul>\n