- El equipo de seguridad del kernel de Linux corrige las vulnerabilidades reportadas lo más rápido posible y las integra en el repositorio público, sin hacer avisos ni anuncios por separado
- Este equipo es independiente del equipo CVE del kernel encargado de emitir CVE; todos participan a título personal y operan sin relación con la empresa a la que pertenezcan
- Los errores de seguridad se tratan igual que los errores comunes y, una vez corregidos, no se marcan como “parches de seguridad” por separado
- No se mantiene un embargo de más de 7 días, y la mayoría de las correcciones se hacen públicas de inmediato
- Este enfoque toma en cuenta la naturaleza del código abierto y la diversidad de entornos de uso, y mantiene la transparencia e independencia de la respuesta de seguridad del kernel
El papel del equipo de seguridad del kernel de Linux
- El equipo de seguridad del kernel es un grupo de desarrolladores que clasifica posibles errores de seguridad reportados y los corrige con rapidez
- Se encargan de una respuesta de seguridad reactiva (reactive), aparte de las medidas preventivas de largo plazo que lleva a cabo el Kernel Self-Protection Project
- El proceso de reporte se hace mediante un simple correo electrónico de texto; no se permiten HTML, archivos adjuntos binarios ni cifrado
- Los reportes cifrados no pueden procesarse debido a la estructura de múltiples destinatarios
- Los miembros del equipo son desarrolladores clave que representan los principales subsistemas del kernel, y no pueden compartir el contenido de las discusiones con sus empleadores ni con terceros
- Gracias a esta independencia, es posible mantener una respuesta consistente sin importar requisitos legales de distintos países (como la CRA)
Proceso de corrección de errores
- Si el error reportado está relacionado con un subsistema específico, se resuelve incluyendo al mantenedor de ese subsistema en la discusión por correo electrónico
- En subsistemas donde los problemas se repiten con frecuencia, el mantenedor puede participar directamente en la lista de correo del equipo de seguridad
- Si quien reporta aporta un parche de corrección, se le reconoce el mérito; si no, los desarrolladores lo resuelven por su cuenta
- Una vez terminada la corrección, se integra en la rama principal del kernel y en las versiones estables (stable)
Política de embargo
- No se permite un periodo de embargo superior a 7 días, y la mayoría de las correcciones se publican de inmediato
- Después de la corrección, solo si quien reportó el problema lo desea puede hacerse un anuncio externo, y el propio equipo de seguridad no hace ningún anuncio
- La asignación de CVE la realiza después el equipo CVE del kernel, que es independiente del equipo de seguridad
El principio de “un bug es solo un bug”
- En 2008, Linus Torvalds dejó claro que los errores de seguridad no deben marcarse por separado
- La razón es que la categoría de “corrección de seguridad” distorsiona la importancia de otros errores
- Todas las correcciones de errores son igual de importantes, y se integran de inmediato sin distinguir entre seguridad, funcionalidad o rendimiento
Por qué no hay avisos de seguridad
- Casi cualquier error a nivel de kernel puede convertirse potencialmente en un problema de seguridad
- Puede tomar muchas formas, como fugas de memoria, denegación de servicio o filtración de información
- Por la naturaleza del código abierto, los desarrolladores no pueden saber cuál es el entorno real de cada usuario
- Una corrección menor para un usuario puede ser una vulnerabilidad crítica para otro
- Por eso, la política es simple
- Corregir de inmediato los errores conocidos
- Distribuir las versiones corregidas lo más rápido posible
- La postura es que, más que preocuparse por que “una corrección pueda causar problemas”, es más riesgoso dejar un error conocido sin atender
Problemas de seguridad de hardware
- Casos como Spectre y Meltdown, que abarcan tanto el sistema operativo como el hardware, requieren procedimientos excepcionales
- Para ello existe la ‘Hardware Security Policy’, que permite colaborar mediante una lista de correo cifrada y restringida
- Este proceso es lento y complejo, pero recientemente muchos errores de hardware se han resuelto sin recurrir a este procedimiento
- En el futuro, los requisitos de tiempo de respuesta de la ley CRA probablemente harán aún más difícil mantener confidencialidad a largo plazo
Cómo nació el equipo de seguridad del kernel
- Antes de 2005, no existía un canal oficial de contacto de seguridad
- Los reportes se hacían solo a través de una red informal entre desarrolladores
- En 2005, la discusión comenzó con una propuesta por correo electrónico de Steve Bergman, y
luego Chris Wright escribió un parche para agregar un contacto de seguridad y documentación
- Después se formalizó un alias central de correo electrónico (security@kernel.org)
Ausencia de avisos de seguridad y de alertas anticipadas
- El equipo de seguridad del kernel no opera ningún tipo de aviso de seguridad ni lista de alertas anticipadas
- La asignación de identificadores CVE está a cargo del equipo CVE del kernel, y el equipo de seguridad no participa en ello
- Aunque hay muchas solicitudes para una lista de alertas anticipadas, no existe debido al riesgo de filtraciones y al principio de publicidad
- La postura es: “si un gobierno permitiera eso, ese proyecto probablemente no se estaría usando realmente”
1 comentarios
Comentarios en Hacker News
Últimamente están avanzando rápido las tecnologías que hacen más fluida la experiencia de virtualización en el escritorio Linux
Los drivers de GPU ya soportan contextos nativos a través de Mesa, y también están mejorando las funciones compartidas entre invitado y host en Wayland
Antes hacían falta análisis complejos de protocolos como sommelier o wayland-proxy-virtwl, pero ahora el proyecto wl-cross-domain-proxy lo está implementando correctamente
Entre los VMM que aprovechan estas funciones están muvm, y como solución que integra todo eso está munix
Estaría genial poder pausar, transferir y reanudar una máquina virtual de esa forma
Por eso Red Hat sigue siendo importante incluso en 2025
Este tipo de trabajo de infraestructura siempre hace falta
Cuando Red Hat hace cherry-pick de commits relacionados con seguridad, si upstream no indica cuáles commits están relacionados con seguridad, ¿cómo se supone que van a saberlo?
A veces sueño con un OS 100% seguro
Tal vez la verificación formal o Rust sean la clave
Me gustaría tener la certeza de que no me van a hackear
Al final, los humanos mismos son la mayor vulnerabilidad
Incluso se verificó hasta el ensamblador, y Dafny salió de ahí
Pero en el mercado se prioriza “entregar rápido” por encima de la buena calidad, así que pasarán décadas antes de que ideas así se vuelvan dominantes
Para aislamiento real se necesita virtualización o separación física
Por eso es difícil reunir muchos colaboradores para un “OS 100% seguro”
Aun así, si te interesa este tema, hay varios proyectos de desarrollo de OS
La seguridad es una carrera sin fin
Por otro lado, aunque ya es 2026, el sitio web personal de Greg todavía no soporta TLS
Configurarlo con Caddy es fácil, pero si es un sitio estático como un blog personal, el beneficio real del cifrado es mínimo
De todos modos el dominio y la IP quedan expuestos en texto plano, así que no hay tanta diferencia
Si de verdad piensan así, ¿no deberían haber eliminado el CNA?
Pero algunos investigadores tienden a inflar el número de CVE, y tratan de dar alta prioridad incluso a bugs que en realidad son inofensivos
“Si obligas a usar cifrado para reportar problemas de seguridad, reconsidera esa política (hablo del gobierno del Reino Unido)”
Esa parte simplemente da risa
Decir que “un bug es solo un bug” es simplificar demasiado
Un DoS que requiere privilegios de root y una toma total del sistema desde un usuario sin privilegios son cosas completamente distintas
Algunos bugs claramente provocan una violación del límite de seguridad, y esos deberían clasificarse como bugs de seguridad
Esto se le ha explicado a Greg desde hace décadas
En conclusión, si no usas la versión más reciente, el kernel queda completamente sin todos los parches
Se evitan los CVE, las correcciones de vulnerabilidades quedan escondidas en el log de commits, y los atacantes se dan cuenta al revisarlo
No entiendo por qué habría que enfatizarlo tanto
Los clientes piden parches relacionados con el kernel dentro de imágenes Docker
Pero Docker ni siquiera incluye el kernel
Debería existir una forma de distribuir imágenes sin kernel
Las imágenes base normales no incluyen el kernel