En 2021, hay más razones por las que la gente ama Linux que nunca. En esta serie, compartiré 21 razones diferentes para usar Linux. Este artículo analiza la influencia de Linux en la seguridad del software de código abierto.
Una virtud a menudo alabada del software de fuente abierta es que su código puede ser revisado (o "auditado", como les gusta decir a los profesionales de la seguridad) por todos y cada uno. Sin embargo, si realmente le pregunta a muchos usuarios de código abierto cuándo fue la última vez que revisaron el código, es posible que obtenga respuestas que van desde una mirada en blanco hasta un murmullo de vergüenza. Además, existen algunas aplicaciones de código abierto realmente grandes, por lo que puede ser difícil revisar cada línea de código de manera efectiva.
Extrapolando estas verdades ligeramente incómodas, debe preguntarse:cuando nadie mira el código, ¿realmente importa si está abierto o no?
¿Deberías confiar en el código abierto?
Tendemos a hacer una suposición trillada en la informática de aficionados de que el código abierto es "más seguro" que cualquier otra cosa. No solemos hablar sobre lo que eso significa, cuál es la base de comparación ("¿más" segura que qué?), o cómo se ha llegado a la conclusión. Es una declaración peligrosa porque implica que siempre que llame a algo código abierto , automáticamente y mágicamente hereda seguridad mejorada. De eso no se trata el código abierto y, de hecho, es contra lo que está muy en contra la seguridad de código abierto.
Nunca debe asumir que una aplicación es segura a menos que haya auditado personalmente y entendido su código. Una vez que haya hecho esto, puede asignar máxima confianza a esa aplicación. La máxima confianza no es algo que se hace en una computadora; es algo que haces en tu propia mente:confías en el software porque eliges creer que es seguro, al menos hasta que alguien encuentre una manera de explotar ese software.
Eres la única persona que puede depositar la máxima confianza en ese código, por lo que todos los usuarios que deseen ese lujo deben auditar el código por sí mismos. ¡Tomar la palabra de otra persona no cuenta!
Entonces, hasta que haya auditado y entendido una base de código por sí mismo, el nivel de confianza máximo que puede otorgar a una aplicación es un espectro que va desde aproximadamente, no confiable en absoluto a bastante confiable . No hay hoja de trucos para esto. Es una elección personal que debes hacer por ti mismo. Si ha escuchado de personas en las que confía firmemente que una aplicación es segura, es posible que confíe más en ese software que en algo para lo que no ha recibido recomendaciones confiables.
Debido a que no puede auditar el código propietario (fuente no abierta), nunca puede asignarle última confianza .
Ley de Linus
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
La realidad es que no todos son programadores, y no todos los que son programadores tienen tiempo para dedicarse a revisar cientos y cientos de líneas de código. Entonces, si no va a auditar el código usted mismo, entonces debe elegir confiar (hasta cierto punto) en las personas que hacen código de auditoría.
Entonces, ¿quién audita exactamente el código?
La Ley de Linus afirma que con suficientes ojos, todos los errores son superficiales , pero en realidad no sabemos cuántos globos oculares son "suficientes". Sin embargo, no subestimes el número. Muy a menudo, el software es revisado por más personas de las que podría imaginar. El desarrollador o los desarrolladores originales obviamente conocen el código que han escrito. Sin embargo, el código abierto es a menudo un esfuerzo de grupo, por lo que cuanto más tiempo está abierto el código, más desarrolladores de software terminan viéndolo. Un desarrollador debe revisar partes importantes del código de un proyecto porque debe aprender una base de código para escribir nuevas funciones para él.
Los empaquetadores de código abierto también se involucran en muchos proyectos para que estén disponibles para una distribución de Linux. A veces, una aplicación se puede empaquetar casi sin estar familiarizado con el código, pero a menudo un empaquetador se familiariza con el código de un proyecto, porque no quiere firmar un software en el que no confía y porque es posible que tenga que hacer modificaciones. para que se compile correctamente. Los reporteros de errores y los clasificadores a veces también se familiarizan con una base de código mientras intentan resolver anomalías que van desde peculiaridades hasta fallas importantes. Por supuesto, algunos reporteros de errores revelan inadvertidamente las vulnerabilidades del código no al revisarlo ellos mismos, sino al llamar la atención sobre algo que obviamente no funciona como se esperaba. Los administradores de sistemas con frecuencia se familiarizan íntimamente con el código de un software importante en el que confían sus usuarios. Por último, hay investigadores de seguridad que profundizan en el código exclusivamente para descubrir posibles vulnerabilidades.
Confianza y transparencia
Algunas personas suponen que debido a que el software principal se compone de cientos de miles de líneas de código, es básicamente imposible de auditar. No se deje engañar por la cantidad de código que se necesita para ejecutar una aplicación. En realidad no tienes que leer millones de líneas. El código está muy estructurado y las fallas explotables rara vez son solo una línea oculta entre los millones de líneas; generalmente hay funciones completas involucradas.
Hay excepciones, por supuesto. A veces, una vulnerabilidad grave se habilita con solo una llamada al sistema o al vincularse a una biblioteca defectuosa. Afortunadamente, ese tipo de errores son relativamente fáciles de detectar, gracias al papel activo de los investigadores de seguridad y las bases de datos de vulnerabilidades.
Algunas personas apuntan a los rastreadores de errores, como el sitio web de Vulnerabilidades y exposiciones comunes (CVE), y deducen que en realidad es tan claro como el agua que el código abierto no es seguro. Después de todo, se presentan cientos de riesgos de seguridad contra muchos proyectos de código abierto, a la vista de todos. Sin embargo, no dejes que eso te engañe. El hecho de que no pueda ver las fallas en el software cerrado no significa que esas fallas no existan. De hecho, sabemos que lo hacen porque también se presentan exploits contra ellos. La diferencia es que todos Los exploits contra aplicaciones de código abierto están disponibles para que los desarrolladores (y usuarios) los vean, de modo que se puedan mitigar esas fallas. Eso es parte del sistema que aumenta la confianza en el código abierto y falta por completo en el software propietario.
Es posible que nunca haya "suficientes" ojos en ningún código, pero cuanto más fuerte y diversa sea la comunidad en torno al código, más posibilidades hay de descubrir y corregir las debilidades.
Confianza y personas
En código abierto, la probabilidad de que muchos desarrolladores, cada uno trabajando en el mismo proyecto, hayan notado algo no seguro pero todos han permanecido igualmente en silencio acerca de que ese defecto se considera bajo porque los humanos rara vez acuerdan mutuamente conspirar de esta manera. Hemos visto lo inconexo que puede ser el comportamiento humano recientemente con la mitigación de la COVID-19:
- Todos hemos identificado una falla (un virus).
- Sabemos cómo evitar que se propague (quédate en casa).
- Sin embargo, el virus continúa propagándose porque una o más personas se desvían del plan de mitigación.
Lo mismo es cierto para los errores en el software. Si hay un defecto, alguien que lo note lo sacará a la luz (siempre y cuando, por supuesto, alguien lo vea).
Sin embargo, con el software propietario, puede haber una alta probabilidad de que muchos desarrolladores que trabajan en un proyecto noten algo que no es seguro, pero permanezcan igualmente en silencio porque el modelo propietario se basa en cheques de pago. Si un desarrollador habla en contra de una falla, en el mejor de los casos ese desarrollador puede dañar la reputación del software, disminuyendo así las ventas, o en el peor de los casos, puede ser despedido de su trabajo. Los desarrolladores a los que se les paga por trabajar en software en secreto no suelen hablar de sus fallas. Si alguna vez ha trabajado como desarrollador, probablemente haya firmado un NDA y le hayan dado lecciones sobre la importancia de los secretos comerciales, etc. El software patentado alienta, y más a menudo impone, el silencio incluso ante fallas graves.
Confianza y software
No confíes en software que no hayas auditado.
Si debe confiar en el software que no ha auditado, elija confiar en el código que está expuesto a muchos desarrolladores que, de forma independiente, probablemente hablen sobre una vulnerabilidad.
El código abierto no es intrínsecamente más seguro que el software propietario, pero los sistemas existentes para solucionarlo están mucho mejor planificados, implementados y dotados de personal.