Seguridad

CaudalGhost observa tu red; nunca interfiere. Esa postura —medir sin tocar— es también la base de su seguridad. Esta página explica el diseño que te protege, qué endurecemos con el tiempo y, con honestidad, qué límites tiene.

Una idea guía todo lo demás: ningún software es invulnerable. La seguridad no es una promesa de que nada pueda romperse, sino el trabajo de subir el costo —en tiempo, dinero y personas— de intentarlo. Todo lo que sigue va en esa dirección.

El diseño que te protege

• El daemon no corre como root. caudalghostd funciona como un usuario de sistema dedicado, con solo dos permisos del kernel (CAP_BPF y CAP_PERFMON) y sin poder escalar (NoNewPrivileges). La instalación pide privilegios (sudo) una vez; el uso diario, no. No es “root con buenos modales”: es un proceso que ni siquiera tiene la capacidad de hacer casi nada fuera de contar bytes.
• No puede llamar a casa, por construcción. La configuración de systemd restringe al daemon a sockets locales (AF_UNIX/AF_NETLINK): no puede abrir una conexión de red aunque quisiera. Sin telemetría, sin analítica, sin identificadores: tus datos nunca salen del equipo. Y cuando haya una actualización, la instalas por los canales de software de tu sistema —cuando tú decides—; el daemon nunca contacta a nadie por su cuenta.
• Sin superficie de red. Los clientes (GUI, terminal, línea de comandos) hablan con el daemon por un socket Unix local con permisos 0660 y una ACL POSIX por usuario. No hay puerto TCP abierto ni servidor web que atacar desde fuera.
• Solo observa. Cuenta bytes dentro del kernel (eBPF). No inspecciona el contenido del tráfico, no bloquea, no modela. Menos capacidades = menos que puede salir mal.
• Tus datos son locales. El histórico vive en un SQLite en tu equipo. Nada sale de la máquina. (El detalle está en Privacidad y datos.)
• Libre y auditable. El código es abierto (AGPL-3.0; la pieza eBPF, GPL-2.0). No tienes que confiar en nuestra palabra: puedes leerlo, compilarlo y verificarlo.

La frontera de confianza

El límite de seguridad es el daemon. Los clientes corren sin privilegios, y el daemon no da por buena ninguna petición solo porque venga de un cliente: la valida y la trata como potencialmente hostil hasta comprobar que no lo es. Una petición malformada jamás debe tumbarlo; a lo sumo, cierra esa conexión y sigue.

Ese contrato lo respaldamos con pruebas: el parser del protocolo y la atribución de aplicaciones se someten a fuzzing (millones de entradas basura automáticas) y a pruebas de regresión que garantizan que ninguna entrada rara provoque una caída.

Qué endurecemos versión a versión

La seguridad no es una casilla que se marca una vez. Cada versión suma capas:

• Sandbox del sistema. El servicio corre con un aislamiento estricto de systemd (sistema de archivos en solo lectura, sin acceso a dispositivos, sin privilegios nuevos).
• Cadena de suministro vigilada. La integración continua audita las dependencias en cada cambio: vulnerabilidades conocidas, licencias, secretos filtrados y patrones de código inseguro. Todas las dependencias provienen de fuentes verificadas.
• Fuzzing continuo. En nuestras pruebas (no en tu equipo), los puntos que reciben entrada no confiable se martillean con millones de entradas aleatorias para descubrir fallos antes de que lleguen a ti.
• Builds más limpios. Los binarios que publicamos no filtran rutas internas del equipo de desarrollo, un paso hacia compilaciones reproducibles.

Riesgos que aceptamos con honestidad

Preferimos documentarlos a esconderlos:

• No prometemos invulnerabilidad. Como cualquier software, CaudalGhost puede tener fallos. Nuestro compromiso es diseñar para minimizarlos, corregir rápido y contarte la verdad.
• Un aviso de la edición gráfica. La edición con interfaz gráfica arrastra, a través de su motor de ventanas, una biblioteca del sistema con un problema conocido de terceros. No afecta al daemon, a la terminal ni a la edición servidor (esos no la usan), y nuestro propio código no toca la parte afectada. El arreglo depende de que el proyecto de terceros actualice su pila; lo tenemos en seguimiento y lo aplicaremos en cuanto esté disponible.
• Atribución best-effort. Asociar tráfico a la app correcta se hace en el momento de la captura, pero en casos raros (cuando el sistema recicla muy rápido el identificador de un proceso) puede atribuirse mal. Es una limitación de precisión, no un problema de seguridad.

Cómo reportar un problema

Si encuentras una vulnerabilidad, ayúdanos con una divulgación coordinada:

• Escribe a [email protected] con el prefijo [security] en el asunto. Si lo prefieres, puedes cifrar el correo con GPG.
• No abras un issue público para fallos de seguridad.
• Incluye la versión afectada, la edición (escritorio o servidor), los pasos para reproducir y el impacto estimado.

Recibirás acuse lo antes posible. Trabajamos el arreglo y coordinamos la publicación contigo; si lo deseas, te acreditamos en las notas de versión. El detalle formal de esta política vive en el archivo SECURITY.md del repositorio.