Una nueva distro Linux basada en Debian llamada Subgraph OS apuesta por un sistema seguro para usuarios sin perfil técnico y con un consumo de recursos comedido. Es la respuesta a soluciones similares mucho menos eficientes.
Cualquier cargo público del PP que se dedique a lo de las "mordidas del 3%"
- No tiene perfil técnico
- Están obsesionados por la seguridad de las comunicaciones; ejemplos:"1,2,3,4,5,6,7,8,9,10,11,12, un millón" "Por que lo dice la jefa"
Cualquier cargo público del PP que se dedique a lo de las "mordidas del 3%"
- No tiene perfil técnico
- Están obsesionados por la seguridad de las comunicaciones; ejemplos:"1,2,3,4,5,6,7,8,9,10,11,12, un millón" "Por que lo dice la jefa"
#3 Es fácil de entender: Cada vez se hay más noticias relacionadas con la seguridad y privacidad en la red que tienen mucha repercusión y eso hace que la gente se preocupe sobre el tema. Ahora bien, preocuparse porque la NSA/FBI puede tener acceso a tus archivos de Dropbox no significa que esa misma gente sepa montarse una nube con Owncloud en su casa.
La semana pasada alguien me habló sobre la privacidad en el caso de Gmail y dudo que esa persona sepa montarse un servidor de correos y cifrar todos los mensajes con gpg.
#3 De la misma forma que puedes estar obsesionado con la seguridad en tu automóvil sin tener una ingeniería. Miras lo que ofrece el mercado y después de ver los análisis de organismos independientes como Euro NCAP o el IIHS tomas una decisión. Claro que, ahora que lo pienso, no existe ningún organismo similar en el campo de sistemas operativos ¿no?
A mi con estas cosas siempre me queda la idea suspicaz de que estas herramientas fáciles de seguridad para no-técnicos pueden ser una especie de honeypot para cazar gente que quiere hacer "cosas malas".
Genial. Muchos la utilizarán para subir sus fotos a facebook y anunciar a bombo y platillo que están de vacaciones (olvidando que es equivalente a decir "no hay nadie en casa").
#26 Hasta que el bug es en el kernel y desde un container puden petarte el host. O petar el host y acceder a todos los contenedores.
Docker usa cgroups y otras funcionalidades DEL KERNEL, no es que Docker implemente nada. Sigue aislando más una máquina virtual, pero son muy convenientes.
Pero claro, no les mola implementar GrSec/PaX en el kernel no sea que afecte el performance.
En Xen, y similares si el bug no está en el hypervisor aunque te peten el kernel del guest no hay problema.
#27 GrSec/PaX también protegen contra algunos bugs dentro del kernel.
Pero si te gusta más fiarte de un hipervisor... ¿cómo harías para ejecutar aplicaciones de escritorio aisladas dentro de VMs? ¿pondrías el hipervisor debajo del kernel, con PCI pass-through y una tarjeta gráfica con monitor separado para cada aplicación? ¿o pondrías el hipervisor encima del kernel para que pudiesen aparecer todas en el mismo monitor, y efectivamente acabrías como con docker solo que con una capa de ralentización más?
#28 Sobre el tema de GrSec: claro, por eso lo he mencionado BASTANTE claramente no se porque repites mis frases. Pero no viene por defecto en el Kernel la funcionalidad, porque Torvalds no quiere. Así que si lo quieres poner tienes que parchear.
No es una cuestión de "fiarme del hypervisor", si no que le Kernel de Linux es MUCHO más complejo que un hypervisor con muchísima menos superficie de ataque. Y no solo problemas de seguridad, si no de máquinas quedándose colgadas,etc.
De hecho KVM (¿has usado oVirt?) tiene este problema también... que está dentro del Kernel tal cual, solo tienes que comparar Xen con KVM.
Respecto al resto de tu comentario, incluyendo el PCI pass-through, han salido recientemente muchas cosas pero vamos: https://www.qubes-os.org/ la virtualización vía Xen.
"Qubes OS is a security-focused desktop operating system that aims to provide security through isolation.[6] Virtualization is performed by Xen, and user environments can be based on Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.[7][8]" Que lo usa mucha gente a diario.
Luego tienes un montón de historias menos curradas en plan Citrix que no son el caso que nos ocupa pero va bien mencionar y sobre lo que has dicho de "VMware" lleva Linux, en fin, sin comentarios. Y sí, no te digo que no sea un kernel modificado,etc. Yo he estado siguiendo el caso de la violación de la GPL también... de ahí a decir "lleva Linux"...
#29#30 No sé cómo crees que funciona un hipervisor, y cómo crees que funciona docker, pero no sé si eres consciente de que un "kernel sobre una VM sobre un hipervisor sobre un kernel" tiene mayor superficie de ataque que un "docker sobre un kernel" a secas. Añadir un hipervisor en medio no crea "un nivel más de separación", aunque lo parezca a primera vista, solo añade más código potencialmente vulnerable.
Lo de "kernel sobre VM sobre hipervisor sobre kernel" es lo que hace Qubes OS, por cierto.
La alternativa es usar "kernel sobre VM sobre hipervisor (bare metal)", con hardware asignado en exclusiva a tal o cual VM... cosa que hace bastante imposible el mostrar ventanitas de todas las VMs en un mismo escritorio en la misma máquina.
Luego ya no sé a qué te refieres con lo de "puertes e IPs privadas", dado que el problema es igualito que con VMs. A ver si es que has mirado un docker de hace la tira de años, o qué. Y si no sabes usar "backups, cronjobs, logging persistente, etc." en docker... pues qué te voy a decir... aprende. Te aseguro que es incluso más fácil que con una VM.
#31 Cuando vayas a discutir conmigo por favor evita poner en mi boca cosas que no he dicho e inventarte paranoias, y intenta leer mejor o no vengas fumado de porros porque escribes cosas muy raras. No me gusta perder el tiempo, pero que no se diga:
Punto 1
"Y si no sabes usar "backups, cronjobs, logging persistente, etc."
Tareas triviales en un bare metal o una VM se complican cuando usas contenedores, nadie ha dicho que no sepa usarlo o que no sea posible. Aparte, no es un tema de "usar" si no de establecer una arquitectura y automatizar. De ahí que se use CoreOS, etcd,confd. Y existan plataformas y software como Shipyard y otras tantas histories con Docker.
Como digo, no asumas cosas ni pongas cosas que yo no he dicho.
Punto 2
No se ni como empezar con esto, pero de nuevo, por favor. No te inventes cosas que no he dicho. "No sé cómo crees que funciona un hipervisor, y cómo crees que funciona docker" y resto del primer párrafo de #31
Ni el hypervisor va en medio de nada ni mierdas. Vamos a ver si te lo pongo simple:
** Situacion A
-Kernel + Docker => fallo en kernel te da accesso a todos los Contenedores.
(Pasa que fallos del kernel hay cada dos por tres (puedes parchear con GrSec,etc. Por supuesto).)
** Situación B
-Hypervisor + VMs => puede fallar una VM, no te da acceso al resto. Puedes tener Docker dentro de una VM, si quieres.
Un hypervisor, a priori, tiene menos código y es mucho más ligero que un kernel (de Linux) tal cual, más fácil de auditar. Por tanto, menos superficie de ataque ya que ese kernel NO CORRE mil servicios, drivers, etc. Su función está más acotada. Es más, puede que tu VM tenga un kernel monolítico y que tu hypervisor sea microkernel.
Claramente, B expone menos superficie que A en condiciones normales. Obviamente si el hypervisor es una basura o si hay un bug en el hypervisor (Xen) puedes ganar root y eventualmente acceder a todas las VM del host.
Punto 3
"Luego ya no sé a qué te refieres con lo de "puertes e IPs privadas""
Me refiero, a que si tienes un contenedor que necesita el puerto 80 en el host (nginx, lo que sea) pues vas a tener que usar un load balancer o el mecanismo que prefieras (IPs, lo que quieras) para poder exponer tu servicio si hay varios contenedores que usan ese puerto en el host. Ni más ni menos que con una VM. Excepto, que en Docker vas a tener cientos de contenedores en una plataforma seria y se da por sentado que ese componente es obligatorio.
Lo mismo que una manera adecuada de resolver internamente DNS para los contenedores, simplificando el proceso de orquestración.
Básicamente era un apunte, bastante obvio. Si solo tienes un contenedor, bueno... te da igual. Veo que no te ha resultado obvio.
Punto 4
"Lo de "kernel sobre VM sobre hipervisor sobre kernel" es lo que hace Qubes OS, por cierto."
#28 Nota aparte sobre "docker y una sola capa de ralentización más":
1- Ganarías también más seguridad, como digo.
2- No se cual crees que es el overhead de una VM, depende mucho del hypervisor. Pero no se si eres consciente de que usan muchas técnicas para compartir memoria, y acceder al hardware de forma transparente.
En fin, Docker en particular como tecnología de contenedores aún tiene que madurar un poco (ahora hay una pelea con systemd, no se si has leído algo) pero está muy bien. Y tanto VMs como contenedores tienen su uso, y se pueden complementar aunque a priori parezcan excluyentes.
Obviamente lanzar un contenedor es mucho más rápido que lanzar una VM, pero en un contenedor tienes otros problemas:
- Un nivel menos de separación y por tanto menos seguridad. Punto. (al menos hablando de Docker en el Kernel de Linux).
- Problemas con puertos e IPs privadas que deben ser expuestas en el host. Nada grave, pero hay que tenerlo en cuenta cuando tienes 200 contenedores, o 65000.
- Gestionar backups, cronjobs, logging persistente, etc. No es tan trivial en un contenedor como lo es usando una VM.
Y otros ejemplos que seguro se te ocurrirán.
Resumiendo: Docker está muy bien pero los contenedores no son la panacea y aún menos en seguridad. Pero sí es muy útil y muy interesante y mejora la seguridad en general así como procesos de desarrollo,etc.
A la vista de las ISOs comprometidas de Linux Mint, en las que un hacker habría introducido una puerta trasera, también se ha estado trabajando en un sistema de verificación del sistema operativo para asegurar que hemos descargado una versión legítima.
Ese sistema de verificación existe hace décadas y es muy fácil de usar: firmar el hash. Aunque ayer en el hilo de Transmission algunos expertos de ciberseguridad de Menéame parecían disentir
Otra cosa es que seas un irresponsable o te importe un comino la seguridad (véase Mint y Transmission).
Qué guay! Un SO en el que no puedes hacer nada, y lo poco que puedes hacer será cerrar ventanitas de avisos cada media hora.
Además, para qué necesitamos esos avisos en tiempo de ejecución? No habíamos quedado en que al ser software abierto, todos podemos conocer al detalle lo que hace nuestro software?
El software abierto sirve para poder analizar el código una vez que detectas un fallo, no para detectar el fallo en primer lugar.
El software libre sirve para además poder corregir ese fallo una vez detectado y analizado.
Y si te salen ventanitas de aviso "cada media hora"... revisa bien tu sistema de una vez, o deja de bajar mierdas.
El mayor fallo de seguridad generalizado de todas las distros linux actuales, es la falta de un firewall saliente que controle lo que hacen las aplicaciones, seguido de la no-activación intencionada de mecanismos de seguridad como GrSec, PaX, SELinux, AppArmor, etc.
Me alegra ver que por fin alguien se está poniendo en serio con el tema.
Comentarios
Una distro de Linux para obesos , ¡qué genialidad! Seguro que bate records en Distrowatch.
#1 Distro, pecadorrr de la pradera
No entiendo cómo alguien puede estar obsesionado con la seguridad y no tener un perfil técnico. Es contradictorio
#3 Te pongo un ejemplo:
Cualquier cargo público del PP que se dedique a lo de las "mordidas del 3%"
- No tiene perfil técnico
- Están obsesionados por la seguridad de las comunicaciones; ejemplos:"1,2,3,4,5,6,7,8,9,10,11,12, un millón" "Por que lo dice la jefa"
#4 Ya pero el leifmotiv de ser corrupto es poder usar cosas selectas como iPads. No cosas raras gratuitas de rojos perroflautas.
#3 El miedo es libre.
#3 Es fácil de entender: Cada vez se hay más noticias relacionadas con la seguridad y privacidad en la red que tienen mucha repercusión y eso hace que la gente se preocupe sobre el tema. Ahora bien, preocuparse porque la NSA/FBI puede tener acceso a tus archivos de Dropbox no significa que esa misma gente sepa montarse una nube con Owncloud en su casa.
La semana pasada alguien me habló sobre la privacidad en el caso de Gmail y dudo que esa persona sepa montarse un servidor de correos y cifrar todos los mensajes con gpg.
#3 De la misma forma que puedes estar obsesionado con la seguridad en tu automóvil sin tener una ingeniería. Miras lo que ofrece el mercado y después de ver los análisis de organismos independientes como Euro NCAP o el IIHS tomas una decisión. Claro que, ahora que lo pienso, no existe ningún organismo similar en el campo de sistemas operativos ¿no?
#3 Arch Linux full disk encryption.
#3 Otro ejemplo. Periodistas que tratan temas delicados y no tienen por qué saber nada de seguridad informática.
#3 yo, cuando uso Telegram y no me da la gana de que mis conversaciones las tenga la nsa o el sitel español.
A mi con estas cosas siempre me queda la idea suspicaz de que estas herramientas fáciles de seguridad para no-técnicos pueden ser una especie de honeypot para cazar gente que quiere hacer "cosas malas".
Genial. Muchos la utilizarán para subir sus fotos a facebook y anunciar a bombo y platillo que están de vacaciones (olvidando que es equivalente a decir "no hay nadie en casa").
#9 sus padres seguiran en casa
Había leído "para obesos de la seguridad"
#26 Hasta que el bug es en el kernel y desde un container puden petarte el host. O petar el host y acceder a todos los contenedores.
Docker usa cgroups y otras funcionalidades DEL KERNEL, no es que Docker implemente nada. Sigue aislando más una máquina virtual, pero son muy convenientes.
Pero claro, no les mola implementar GrSec/PaX en el kernel no sea que afecte el performance.
En Xen, y similares si el bug no está en el hypervisor aunque te peten el kernel del guest no hay problema.
#27 GrSec/PaX también protegen contra algunos bugs dentro del kernel.
Pero si te gusta más fiarte de un hipervisor... ¿cómo harías para ejecutar aplicaciones de escritorio aisladas dentro de VMs? ¿pondrías el hipervisor debajo del kernel, con PCI pass-through y una tarjeta gráfica con monitor separado para cada aplicación? ¿o pondrías el hipervisor encima del kernel para que pudiesen aparecer todas en el mismo monitor, y efectivamente acabrías como con docker solo que con una capa de ralentización más?
Y no hablemos de los hipervisores como VMware, que llevan linux: http://laforge.gnumonks.org/blog/20160225-vmware-gpl/
#28 Sobre el tema de GrSec: claro, por eso lo he mencionado BASTANTE claramente no se porque repites mis frases. Pero no viene por defecto en el Kernel la funcionalidad, porque Torvalds no quiere. Así que si lo quieres poner tienes que parchear.
No es una cuestión de "fiarme del hypervisor", si no que le Kernel de Linux es MUCHO más complejo que un hypervisor con muchísima menos superficie de ataque. Y no solo problemas de seguridad, si no de máquinas quedándose colgadas,etc.
De hecho KVM (¿has usado oVirt?) tiene este problema también... que está dentro del Kernel tal cual, solo tienes que comparar Xen con KVM.
Respecto al resto de tu comentario, incluyendo el PCI pass-through, han salido recientemente muchas cosas pero vamos: https://www.qubes-os.org/ la virtualización vía Xen.
"Qubes OS is a security-focused desktop operating system that aims to provide security through isolation.[6] Virtualization is performed by Xen, and user environments can be based on Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.[7][8]" Que lo usa mucha gente a diario.
Luego tienes un montón de historias menos curradas en plan Citrix que no son el caso que nos ocupa pero va bien mencionar y sobre lo que has dicho de "VMware" lleva Linux, en fin, sin comentarios. Y sí, no te digo que no sea un kernel modificado,etc. Yo he estado siguiendo el caso de la violación de la GPL también... de ahí a decir "lleva Linux"...
#29 #30 No sé cómo crees que funciona un hipervisor, y cómo crees que funciona docker, pero no sé si eres consciente de que un "kernel sobre una VM sobre un hipervisor sobre un kernel" tiene mayor superficie de ataque que un "docker sobre un kernel" a secas. Añadir un hipervisor en medio no crea "un nivel más de separación", aunque lo parezca a primera vista, solo añade más código potencialmente vulnerable.
Lo de "kernel sobre VM sobre hipervisor sobre kernel" es lo que hace Qubes OS, por cierto.
La alternativa es usar "kernel sobre VM sobre hipervisor (bare metal)", con hardware asignado en exclusiva a tal o cual VM... cosa que hace bastante imposible el mostrar ventanitas de todas las VMs en un mismo escritorio en la misma máquina.
Luego ya no sé a qué te refieres con lo de "puertes e IPs privadas", dado que el problema es igualito que con VMs. A ver si es que has mirado un docker de hace la tira de años, o qué. Y si no sabes usar "backups, cronjobs, logging persistente, etc." en docker... pues qué te voy a decir... aprende. Te aseguro que es incluso más fácil que con una VM.
#31 Cuando vayas a discutir conmigo por favor evita poner en mi boca cosas que no he dicho e inventarte paranoias, y intenta leer mejor o no vengas fumado de porros porque escribes cosas muy raras. No me gusta perder el tiempo, pero que no se diga:
Punto 1
"Y si no sabes usar "backups, cronjobs, logging persistente, etc."
Tareas triviales en un bare metal o una VM se complican cuando usas contenedores, nadie ha dicho que no sepa usarlo o que no sea posible. Aparte, no es un tema de "usar" si no de establecer una arquitectura y automatizar. De ahí que se use CoreOS, etcd,confd. Y existan plataformas y software como Shipyard y otras tantas histories con Docker.
Como digo, no asumas cosas ni pongas cosas que yo no he dicho.
Punto 2
No se ni como empezar con esto, pero de nuevo, por favor. No te inventes cosas que no he dicho.
"No sé cómo crees que funciona un hipervisor, y cómo crees que funciona docker" y resto del primer párrafo de #31
Ni el hypervisor va en medio de nada ni mierdas. Vamos a ver si te lo pongo simple:
** Situacion A
-Kernel + Docker => fallo en kernel te da accesso a todos los Contenedores.
(Pasa que fallos del kernel hay cada dos por tres (puedes parchear con GrSec,etc. Por supuesto).)
** Situación B
-Hypervisor + VMs => puede fallar una VM, no te da acceso al resto. Puedes tener Docker dentro de una VM, si quieres.
Un hypervisor, a priori, tiene menos código y es mucho más ligero que un kernel (de Linux) tal cual, más fácil de auditar. Por tanto, menos superficie de ataque ya que ese kernel NO CORRE mil servicios, drivers, etc. Su función está más acotada. Es más, puede que tu VM tenga un kernel monolítico y que tu hypervisor sea microkernel.
Claramente, B expone menos superficie que A en condiciones normales. Obviamente si el hypervisor es una basura o si hay un bug en el hypervisor (Xen) puedes ganar root y eventualmente acceder a todas las VM del host.
Punto 3
"Luego ya no sé a qué te refieres con lo de "puertes e IPs privadas""
Me refiero, a que si tienes un contenedor que necesita el puerto 80 en el host (nginx, lo que sea) pues vas a tener que usar un load balancer o el mecanismo que prefieras (IPs, lo que quieras) para poder exponer tu servicio si hay varios contenedores que usan ese puerto en el host. Ni más ni menos que con una VM. Excepto, que en Docker vas a tener cientos de contenedores en una plataforma seria y se da por sentado que ese componente es obligatorio.
Lo mismo que una manera adecuada de resolver internamente DNS para los contenedores, simplificando el proceso de orquestración.
Básicamente era un apunte, bastante obvio. Si solo tienes un contenedor, bueno... te da igual. Veo que no te ha resultado obvio.
Punto 4
"Lo de "kernel sobre VM sobre hipervisor sobre kernel" es lo que hace Qubes OS, por cierto."
NO. https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf
Quebes OS usa Xen, y Xen es un hypervisor. Las máquinas virtuales van dentro del hypervisor.
#28 Nota aparte sobre "docker y una sola capa de ralentización más":
1- Ganarías también más seguridad, como digo.
2- No se cual crees que es el overhead de una VM, depende mucho del hypervisor. Pero no se si eres consciente de que usan muchas técnicas para compartir memoria, y acceder al hardware de forma transparente.
En fin, Docker en particular como tecnología de contenedores aún tiene que madurar un poco (ahora hay una pelea con systemd, no se si has leído algo) pero está muy bien. Y tanto VMs como contenedores tienen su uso, y se pueden complementar aunque a priori parezcan excluyentes.
Obviamente lanzar un contenedor es mucho más rápido que lanzar una VM, pero en un contenedor tienes otros problemas:
- Un nivel menos de separación y por tanto menos seguridad. Punto. (al menos hablando de Docker en el Kernel de Linux).
- Problemas con puertos e IPs privadas que deben ser expuestas en el host. Nada grave, pero hay que tenerlo en cuenta cuando tienes 200 contenedores, o 65000.
- Gestionar backups, cronjobs, logging persistente, etc. No es tan trivial en un contenedor como lo es usando una VM.
Y otros ejemplos que seguro se te ocurrirán.
Resumiendo: Docker está muy bien pero los contenedores no son la panacea y aún menos en seguridad. Pero sí es muy útil y muy interesante y mejora la seguridad en general así como procesos de desarrollo,etc.
A la vista de las ISOs comprometidas de Linux Mint, en las que un hacker habría introducido una puerta trasera, también se ha estado trabajando en un sistema de verificación del sistema operativo para asegurar que hemos descargado una versión legítima.
Ese sistema de verificación existe hace décadas y es muy fácil de usar: firmar el hash. Aunque ayer en el hilo de Transmission algunos expertos de ciberseguridad de Menéame parecían disentir
Otra cosa es que seas un irresponsable o te importe un comino la seguridad (véase Mint y Transmission).
Qué guay! Un SO en el que no puedes hacer nada, y lo poco que puedes hacer será cerrar ventanitas de avisos cada media hora.
Además, para qué necesitamos esos avisos en tiempo de ejecución? No habíamos quedado en que al ser software abierto, todos podemos conocer al detalle lo que hace nuestro software?
#18 No, al menos yo no he "quedado" en eso.
El software abierto sirve para poder analizar el código una vez que detectas un fallo, no para detectar el fallo en primer lugar.
El software libre sirve para además poder corregir ese fallo una vez detectado y analizado.
Y si te salen ventanitas de aviso "cada media hora"... revisa bien tu sistema de una vez, o deja de bajar mierdas.
El mayor fallo de seguridad generalizado de todas las distros linux actuales, es la falta de un firewall saliente que controle lo que hacen las aplicaciones, seguido de la no-activación intencionada de mecanismos de seguridad como GrSec, PaX, SELinux, AppArmor, etc.
Me alegra ver que por fin alguien se está poniendo en serio con el tema.
Parece algo parecido a Qubes OS, pero el artículo no deja bien claras las diferencias.
Supongo que llevará GrSec almenos
porque como tire de docker... (edit: veo que sale GrSec+PaX en la imagen).
#11 QubeOS sería mejor, mira Xen últimamente tampoco es que tenga pocos fallos.
#13 ¿Cuál es el problema con docker? No sustituye a GrSec, pero es una forma muy buena de aislar aplicaciones (cgroups).
#11 #0 https://www.fabiankeil.de/gehacktes/electrobsd/
Subgraph OS... Que nombre más comercial!. Va a arrasar entre los "usuarios sin perfil técnico"
#14 Pues sí, ¿SecurOS está pillado? o Doors 95.
#14 gnu-linux y comercial??
El objetivo no es vender!!! Ni siquiera que la gente lo use!!