"People keep having this delusion that security is a product. That, if you just buy some magic box, you'll have a program or an operating system that's as secure as Fort Knox."
La paradoja es que Fort Knox TAMBIÉN es un producto, y el autor dice que la seguridad está en el proceso (p.e. la videovigilancia de Fort Knox, el entrenamiento de sus guardias, su protocolo de acceso...), NO en el producto (Fort Knox en sí).
Es como decir que un Seat no es seguro (ni inseguro), porque lo que aporta seguridad es conducir bien... y luego añadir: "por eso hay que conducir bien para que un Seat sea tan seguro como un Audi".
Está claro. Cuanto más inseguro sea un producto más tienes que invertir en PROCESOS que suplan la falta de seguridad de los productos. Se trata precisamente de eso, de ahorrar en procesos.
Bueno, tampoco dice nada nuevo: "Linux is insecure. Open source is insecure. Windows is insecure. All software is insecure." Pos vale, podría haber puesto otro título a la 'noticia'
La idea del articulo es intentar explicar que todos los sistemas son inseguros, por lo que se coje un referente que se supone muy seguro (en este caso linux) y se usa en el titulo para llamar la atención.
Yo no lo veo desacertado.
Si, pero fíjate que al final dice: "while you're safer using Linux or open-source software, you're never perfectly safe" Osea, que aunque reconoce que es más seguro usar Linux, simplemente dice que no estás absolutamente seguro.
Si al menos lo hubiera titulado algo así como "Linux no es seguro (y Windows menos aún)" se lo habría 'perdonado'
Pero es que Windows se puede hacer igual de seguro (o más) que cualquier Linux
Es simplementen cuestión de la cantidad de trabajo que te va a llevar hacerlo
#8 Que conste que yo no estoy diciendo lo contrario, sólo estoy poniendo sobre la mesa que el título dice una cosa y lo que desarrolla el artículo casi que dice lo contrario. Sólo denuncio esa disparidad y el titular amarillista que ha puesto
#8 Windows/Software Cerrado no podra ser nunca tan seguro como qualquier Linux/Software Abierto. No es lo mismo tener mil ojos buscando bugs en un codigo cerrado que millones de ojos viendo el codigo fuente (y los posibles bugs que puedan haber en este).
Ahora, si eres un inutil van a ejecutar codigo malicioso en tu maquina aunque usues el ordenador mas seguro del pentagono.
Windows/Software Cerrado no podra ser nunca tan seguro como qualquier Linux/Software Abierto. No es lo mismo tener mil ojos buscando bugs en un codigo cerrado que millones de ojos viendo el codigo fuente (y los posibles bugs que puedan haber en este).
-----------------------
La teoría es muy bonita, pero ¿cuántas personas se molestan realmente en echar un vistazo al código fuente de un programa de software libre?
Y no digamos ya en dedicar el tiempo suficiente a estudiar el código para ser capaces de encontrar errores no evidentes que puedan habersele escapado al programador original, porque si fueran evidentes ya los habría corregido. Requeriría de mucho, mucho tiempo.
Y de todas formas, en el caso de que así fuera, esto no es como echar palas de tierra a un pozo. Llega un momento en que aumentar el número de personas mirando el código no produciría un aumento más que infinitesimal en el número de errores que pudieran encontrar en el código. No me sirve el argumento de más gente mirando = más errores encontrados = más seguro.
Así que no está tan claro que ahora mismo el software libre sea más seguro.
Lo que si está claro es que el diseño de Linux como sistema operativo es una patata
#11, si algo no funciona basta con hacer un "bug report" a un bugzilla. Por ejemplo, para Ubuntu basta con ir a launchpad.net/distros/ubuntu/+filebug. Y esto es algo que sabe hacer cualquiera capaz de postear en un blog.
Luego los "expertos" ya dirán en qué paquete está el bug, si hay que corregirlo, etc. El código fuente ya lo mirará quien lo tenga que mirar.
La ventaja del software libre no (solamente) está en ver el código, sino en el proceso de desarrollo. Cosas como "peer review", desarrollo horizontal, orientar a la compatibilidad, modularización, etc, ayudan a conseguir productos mucho más seguros.
si algo no funciona basta con hacer un "bug report" a un bugzilla
-------------
aunque no lo creas hay empresas que no proporcionan el código de una aplicación pero a las que puedes enviar reportes de error. ¿qué tienen que ver las churras con las merinas?
#15 todo está relacionado. Esas empresas no corregirán los errores, sino que te forzarán a comprar una nueva versión. En cambio en un bugzilla el proceso es transparente, cualquiera puede corregir el bug, puedes ver lo hacen, y puedes aplicar el parche por tu parte.
Hasta hace muy poco, Microsoft (ejemplo) te hacía pagar mucha pasta a cambio de darte el privilegio de reportar bugs.
Las empresas de software privativo pueden intentar imitar el proceso de desarrollo tipo software libre, pero nunca lo conseguirán: al limitar la "libertad" no pueden competir en cuanto a ventajas.
A #13 "Lo que si está claro es que el diseño de Linux como sistema operativo es una patata"
Toma afirmación gratuita menospreciando a un montón de gente que tiene mucha más idea que tú en sistemas operativos.
#15 todo está relacionado. Esas empresas no corregirán los errores, sino que te forzarán a comprar una nueva versión. En cambio en un bugzilla el proceso es transparente, cualquiera puede corregir el bug, puedes ver lo hacen, y puedes aplicar el parche por tu parte.
---------------
el 15 eras tu dzpm
otro mito. firefox tiene algunos bugs en bugzilla que tienen tiempo para haber ido a la mili y haber fundado una familia
Toma afirmación gratuita menospreciando a un montón de gente que tiene mucha más idea que tú en sistemas operativos.
--------
No lo digo yo, lo ha dicho un montón de gente a lo largo de su historia. Entre ellos Tanenbaum, claro, que fue la discusión más famosa.
La discusión de kernel monolítico versus microkernel es antigua y decir que un diseño de sistema operativo es malo por elegir una de las dos opciones es simplista.
Cada uno tiene sus ventajas e inconvenientes y curiosamente la mayoría de sistemas operativos optan por soluciones hibridas. A grosso modo las ventajas de los monolíticos son su simplicidad y su eficiencia y las de los microkernels que un fallo en un subsistema no afecta a los otros subsistemas.
Curiosamente tanto windows nt como mach, que serían los ejemplos de microkernels, no ejecutan en espacio de usuario sus subsistemas importantes por tema de rendimiento, con lo que las ventajas de microkernels desaparecen.
Linux, aunque monolítico, también tiene características diferenciadoras.
La primera y más importante es que permite la carga dinámica de código bajo demanda (los módulos), soporte para kernel threads (algo parecido a los subsistemas pero en kernel mode) además cada vez se pueden ver más cosas, como sistemas de ficheros, que se ejecutan en espacio de usuario.
Obviando toda la discusión de monolítico tenemos otras cosas
Prácticamente todo el kernel está orientado a objeto, con unas clases y funciones definidas, una API reducida, unas convenciones de código, un número importante de arquitecturas en las que está soportado, soporte para SMP (cosa jodidísima de implementar sin un buen diseño) y pequeñas maravillas como el scheduler O(1) que sin duda alguna tienen un diseño moderno, elaborado, eficiente y cualquier antónimo de patata
#11 Simplemente el hecho de que no sólo las personas encargadas de tal proyecto puedan colaborar en él ya hace,en teoría más seguro al software libre frente al privativo.Pero como bien dices,eso es en teoría en la práctica puede ser muy distinto,aún así cabe destacar que ya de por sí el modelo de desarrollo y de resolución de bugs es una gran ventaja a tener en cuenta en lo que a seguridad se refiere.Y por cierto,sí puede que firefox y otros programas tengan bugs ahora que están por resolverlos,pero sí alguien con conocimientos de programación suficiente (seguro que más de uno que haya leído este hilo) se digna a intentar resolverlo puede hacerlo(aunque sea una ardua tarea),en cambio con el software privativo esto es imposible,lo que a mi manera de ver las cosas demuestra que el concepto del que nace el software libre lo hace a éste mas seguro (claro que no todo es teoría...).
Por otra parte he escuchado tantas cosas a favor y en contra del asunto ese de microkernel vs kernel monolítico que ya no sé que pensar :S.
"People keep having this delusion that security is a product. That, if you just buy some magic box, you'll have a program or an operating system that's as secure as Fort Knox."
La paradoja es que Fort Knox TAMBIÉN es un producto, y el autor dice que la seguridad está en el proceso (p.e. la videovigilancia de Fort Knox, el entrenamiento de sus guardias, su protocolo de acceso...), NO en el producto (Fort Knox en sí).
Es como decir que un Seat no es seguro (ni inseguro), porque lo que aporta seguridad es conducir bien... y luego añadir: "por eso hay que conducir bien para que un Seat sea tan seguro como un Audi".
Asegurando un Linux recién instalado de Barry O’Donovan
mundogeek.net/traducciones/odonovan.html
Yo no lo veo desacertado.
Si al menos lo hubiera titulado algo así como "Linux no es seguro (y Windows menos aún)" se lo habría 'perdonado'
Es simplementen cuestión de la cantidad de trabajo que te va a llevar hacerlo
Ahora, si eres un inutil van a ejecutar codigo malicioso en tu maquina aunque usues el ordenador mas seguro del pentagono.
-----------------------
La teoría es muy bonita, pero ¿cuántas personas se molestan realmente en echar un vistazo al código fuente de un programa de software libre?
Y no digamos ya en dedicar el tiempo suficiente a estudiar el código para ser capaces de encontrar errores no evidentes que puedan habersele escapado al programador original, porque si fueran evidentes ya los habría corregido. Requeriría de mucho, mucho tiempo.
Y de todas formas, en el caso de que así fuera, esto no es como echar palas de tierra a un pozo. Llega un momento en que aumentar el número de personas mirando el código no produciría un aumento más que infinitesimal en el número de errores que pudieran encontrar en el código. No me sirve el argumento de más gente mirando = más errores encontrados = más seguro.
Así que no está tan claro que ahora mismo el software libre sea más seguro.
Lo que si está claro es que el diseño de Linux como sistema operativo es una patata
Luego los "expertos" ya dirán en qué paquete está el bug, si hay que corregirlo, etc. El código fuente ya lo mirará quien lo tenga que mirar.
La ventaja del software libre no (solamente) está en ver el código, sino en el proceso de desarrollo. Cosas como "peer review", desarrollo horizontal, orientar a la compatibilidad, modularización, etc, ayudan a conseguir productos mucho más seguros.
-------------
aunque no lo creas hay empresas que no proporcionan el código de una aplicación pero a las que puedes enviar reportes de error. ¿qué tienen que ver las churras con las merinas?
Hasta hace muy poco, Microsoft (ejemplo) te hacía pagar mucha pasta a cambio de darte el privilegio de reportar bugs.
Las empresas de software privativo pueden intentar imitar el proceso de desarrollo tipo software libre, pero nunca lo conseguirán: al limitar la "libertad" no pueden competir en cuanto a ventajas.
Toma afirmación gratuita menospreciando a un montón de gente que tiene mucha más idea que tú en sistemas operativos.
---------------
el 15 eras tu dzpm
otro mito. firefox tiene algunos bugs en bugzilla que tienen tiempo para haber ido a la mili y haber fundado una familia
--------
No lo digo yo, lo ha dicho un montón de gente a lo largo de su historia. Entre ellos Tanenbaum, claro, que fue la discusión más famosa.
groups.google.com/group/comp.os.minix/browse_frm/thread/c25870d7a41696
Y tenía razón en todo lo que decía.
Cada uno tiene sus ventajas e inconvenientes y curiosamente la mayoría de sistemas operativos optan por soluciones hibridas. A grosso modo las ventajas de los monolíticos son su simplicidad y su eficiencia y las de los microkernels que un fallo en un subsistema no afecta a los otros subsistemas.
Curiosamente tanto windows nt como mach, que serían los ejemplos de microkernels, no ejecutan en espacio de usuario sus subsistemas importantes por tema de rendimiento, con lo que las ventajas de microkernels desaparecen.
Linux, aunque monolítico, también tiene características diferenciadoras.
La primera y más importante es que permite la carga dinámica de código bajo demanda (los módulos), soporte para kernel threads (algo parecido a los subsistemas pero en kernel mode) además cada vez se pueden ver más cosas, como sistemas de ficheros, que se ejecutan en espacio de usuario.
Obviando toda la discusión de monolítico tenemos otras cosas
Prácticamente todo el kernel está orientado a objeto, con unas clases y funciones definidas, una API reducida, unas convenciones de código, un número importante de arquitecturas en las que está soportado, soporte para SMP (cosa jodidísima de implementar sin un buen diseño) y pequeñas maravillas como el scheduler O(1) que sin duda alguna tienen un diseño moderno, elaborado, eficiente y cualquier antónimo de patata
Por otra parte he escuchado tantas cosas a favor y en contra del asunto ese de microkernel vs kernel monolítico que ya no sé que pensar :S.