Barrapunto

Here's the translation.

Traducción a continuación:

Hola,
me temo que no hablo español, pero, en cualquier caso, he actualizado las FAQ en el servidor web para hablar de spyware/malware. Espero que esto responda a tu pregunta, quizá alguien pueda escribir una traducción a español aquí.

Gracias - mike (mantenedor de autopackage).

(Next, a translation of the relevant FAQ parts about spyware and malware). Y, ahora, una traducción de los apartados relevantes:

***ATENCIÓN: PARRAFADA LAAARGA*** # No permitirá la falta de firmas la entrada de spyware y malware en Linux, como en Windows?
No. Eso es una falacia. El spyware no proviene de la falta de firmas de paquetes en Windows: de hecho, los propios controles ActiveX tiene firma a menudo y, sin embargo, mucho spyware entra explotando debilidades de ActiveX (por ejemplo, usando objectos que no permiten scripting con seguridad). Microsoft envía a menudo archivos EXE firmados: por ejemplo, empaquetan documentos en ellos.

Spyware se usa más a menudo por vendedores de software propietario como modo de obtener fondos para su desarrollo. Al incluir Gator o porquería similar con su programa, pueden obtener ingresos extra de programas "gratis".

La firma de paquetes en dpkg, rpm y similares no resuelve este problema, porque solamente afecta a software propietario, que no suele aceptarse en esos repositorios de todos modos. Ciertamnete, si un usuario ha decidido que quiere un programa, lo instalará sin importar en qué formato venga: si Linux se mete en medio, le echarán la culpa al sistema operativo, no al vendedor del programa. Autopackage no facilita a los vendedores de software privado el incluir spyware más que Loki Setup.

Al tiempo que ejecutar software propietario en Linux se hace más popular, el spyware probablemente se convierta en un problema. Alguien lo confrontará, pero eso es cosa de otro proyecto.

Por tanto, la verdadera solución a pargo plazo es reemplazar el software propietario del usuario final por software libre. Sin embargo, eso no va a poder hacerse mañana mismo, así que debemos planear con antelación para tratar el periodo de transición (y algún software comercial será quizá siempre privado, como los juegos comerciales).

¿Y cómo luchamos contra el spyware si no lo hacemos a nivel de paquetes?
Básicamente, el asunto es de filtrado y confianza. Sabemos que hay "chikoz maloz" (lo siento, no pude evitar la referencia a Warhammer) que quieren inundar nuestra infrastructura con programas maliciosos, y sabemos que debemos hacer algo para detenerlos. ¿Qué podemos hacer, entonces?

Combatir el spyware es lo mismo que combatir virus y bots. Básicamente se trata de evitar que cierta clase de programas se ejecute. Digo "cierta clase" porque la definición de malicioso varí de persona a persona: realmente hay gente por ahí que instala cosas como Gator deliberadamente, porque le gusta los servicios que les da y no les importa lo que esté haciendo por detrás. Así que lo que es "software malo" para una persona no lo es para otra, y cualquier intento sistemático de excluir programas debe tener eso en cuenta.

Hay varios problemas que hacen difícil esta tarea. El primero es que el código malicioso tiene muchas formas de obtener acceso a la CPU. En el caso má obvio, el usuario puede descargar y ejecutar un troyano. Lo único que podemos hacer aquí es interceptar el intento de ejecución y avisar al usuario de lo que realmente están ejecutando. Esto podrí implementarse en un nuevo módulo de seguridad de Linux que mantenga una base de datos de archivos permitidos y deniegue el permiso de ejecución inicial mientras provoca una comprobación de una lista negra y pregunta al usuario si quiere continuar.

Desafortunadamente, rápidamente se ve que dicha técnica es inefectiva a menos que se use una lista blanca de firmas digitales, pues, de otro modo, se pueden usar contenedores polimórficos para evadir la detección. En otras palabras, si un programa no está firmado por una clave de confianza, se presenta un aviso que indica al usuario que no lo ejecute. La piedra de toque no está en realizar comprobaciones exhaustivas de nuevos vendedors y binarios, sino en hacer muy fácil obtener binarios firmados, y si después causas problemas se puede cancelar rápidamente la clave.

Es muy importante poder obtener una clave de confianza, porque, si no, tienes el mismo problema que Microsoft con los controladores firmados. Con la intención de asegurar un control de calidad de los controladores, Microsoft empezón un programa de firmas por el que tus controladores se someterían al análisis de los Windows Hardware Quality Labs (WHQL) y, si pasaba las pruebas, se firmaría. Si no, el usuario recibiría un aviso cuando instalase el hardware.

Predeciblemente, muchos controladores aún no tienen firma y los usuarios han aprendido a ignorar los avisos. Cualquier aviso o consejo que el ordenador dé DEBE ser preciso, y tener un número mínimo de falsos positivos o el usuario simplemente lo ignorará. Por tanto, para un vendedor de software que puede no merecer tu confianza, es mejor darle una clave y el beneficio de la duda: si resulta que violan las políticas de la red de confianza entonces se cancela la clave en una actualización online antes de que haga demasiado daño. La alternativa es que los usuarios se acostumbren a aceptar software sin firmar, momento en el que la defensa se vuelve inútil.

Hay otras posibles defensas. Tecnologías como Exec-shield y ProPolice pueden ayudar a defendernos de virus y bots que invadirían un ordenador mediante fallos en su construcción. SELinux puede usarse para limitar lo que el código transferible puede hacer, abriendo la posibilidad de software transferible en cliente de gran riqueza que es, sin embargo, seguro: algo que ActiveX y Java intentaron lograr, pero no consiguieron.

Para acabar, no importa lo buenas que sean las defensas que pongamos, inevitablemente se atravesarán. Cuando lo sean, será necesario controlar los daños. Programas como Tripwire pueden supervisar un sistema para detectar cambios inesperados, y se pueden usar buscadores de rootkits para detectar intrusiones. Todos estos programas necesitan adaptarse al escritorio y fundirse en un sistema coherente que se pueda instalar, por defecto, en las distribuciones Linux de escritorio.

De nuevo, es necesario hacer este trabajo, pero no es parte de este proyecto.

Por cierto, esta traducción se puede usar como a cada cual le dé la gana (lo digo por si el mantenedor de autopackage quiere incluirla en una traducción de las FAQ).

Mike (a.k.a. autopackage maintainer), feel free to use this translation if you want to publish a spanish version of your FAQ :-)