Hace 4 años | Por --525300-- a genbeta.com
Publicado hace 4 años por --525300-- a genbeta.com

Hace años que la comunidad de ciberseguridad venía pidiendo este cambio y Linus Torvalds finalmente le ha dado su sello de aprobación

Comentarios

xkill

#1 metería presión a Nvidia y otros fabricantes a hacer OpenSource parte de sus controladores. Si quieres ejecutar código en la máquina que nadie sabe que es, allá tu, desactiva esta mejora de seguridad. En realidad, si ejecutas algo que no sabes que es, estas igualmente vendido.

x

#7 no tiene nada que ver con eso. NVidia no te va a meter un bicho para minar mientras navegas. El bicho te lo vas a meter tú solito cuando navegas con un usuario root porque así te da menos problemas como si estuvieras en XP. O te lo va a meter porque pille alguna de las muchas veces que metes tu contraseña de usuario a lo largo del día en esos sistemas que tienen el sudo configurado para ser root con la contraseña de usuario; metes la contraseña para-lo-que-sea, la captura, prueba a ver si funciona en el sudo y.... los malos ya son root. Pues con esto podrá cambiarte el DNS o ponerte algo en el arranque, pero no manosear el kernel.

xkill

#19 no. Pero Nvidia puede meter , y de hecho ya lo hace, código no standard del kernel el cual no pasa los rigurosos controles del kernel de Linux por lo que puede estar sujeta a vulnerabilidades que den acceso root a "bichos".
Por cierto, para minar no hace falta ser root.

D

#23 #19 Chavales, hace años que los "bichos" se meten en el hardware, precisamente para no tener que lidiar con las actualizaciones de kernel. Cata, que te estás haciendo viejuno! ;-D

anv

#24 Pero a no ser que venga de fábrica en el hardware, para meterse necesitan pasar por el kernel.

xkill

#24 #23 No se muy a bajo nivel como va a funcionar lockdown, pero me imagino que será un firmado forzado del kernel (cosa que ya existe pero no va activada por defecto), de esta manera se evita que drivers no firmados se puedan cargar. Asi que adios a los drivers propietarios o fuera del kernel (a no ser que los firmes tu a mano con un certificado, por lo que, pongo la mano en el fuego, a que el 90% de la gente que haga esto, tendrá la clave privada alojada en el ordenador que corre el kernel, permitiendo así, siendo root, poder firmar modulos y cargarlos sin problema).

Por otro lado esta el tema de la "confidencialidad" que evitaría que desde el espacio de usuario se pueda acceder a la memoria del kernel: me da a mi que con esto los drivers propietarios de nvidia no se van a poder gestionar desde el espacio de usuario (aun siendo root), lo que evitaría poder usar el gestor de configuraciones de nvidia).

Igual que digo "nvidia" digo drivers externos al kernel o aplicaciones que corren en espacio de usuario con acceso directo al hardware, como por ejemplo los lectores de huellas dactilares, y no sé hasta que medida los controles de frecuencia de CPU, ...

Volviendo al tema de los "bichos": si se cuelan en el hardware, o bien están explotando una vulnerabilidad de los drivers o bien se meten en el sistema de arranque (llamalo BIOS, UEFI, o como quieras). Si no permites que desde el espacio de usuario se pueda leer ni escribir en el sistema de arranque o en el firmware de los dispositivos (para lograr ejecución via Hardware), pues se soluciona el problema este.

@dowa : si no voy bien, a ver si arreglas mi comentario

anv

#23 A ver. Lockdown no va a ayudar ni a evitar esto. Lockdown lo que haría, si lo activas, es evitar que una vez arrancado el sistema otros programas carguen módulos en el kernel.

Para un usuario normal esto puede ser molesto. Porque si te da por pinchar un dispositivo USB nuevo no podrás cargar el módulo y tendrás que reiniciar para que funcione. Pero para servidores puede ser un extra de seguridad interesante.

C

La moda Android de evitar el root llegará a Linux. Pero es por nuestro bien.

J

#5 ¿Qué es una "carpeta" del sistema ?

n

#6 /usr /etc /bin /sbin son directorios donde usualmente sólo root podrán escribir. A veces sólo quieres hacer una ñapa en uno de estos directorios y necesitas ser root para escribir en ellos o hacerlo con sudo.

Para este tipo de operaciónes, reiniciar servicios, o simplemente matar procesos no te hace falta acceso al hardware o al propio kernel.

J

#9 Ops... Creo que el sentido de mi comentario no lo he explicado bien...

A

#11 ¿Te refieres a que deberíamos llamarlos "directorios"? La verdad es que la palabra "carpeta" siempre me ha parecido un infantilismo absurdo de los windowseros. Pero ya al final te acostumbras, por que si no, los casuals no te entienden cuando les explicas algo.

j

#12 Para alguien que empezó en la informática con 12 o 13 años con ms-dos lo de los directorios, lo tengo muy marcado ya en el ADN, por que si no recuerdo mal, así se llamaba, directorios. Luego pasé por windows 95, 98, me, 2000, xp y zas a GNU/LINUX, es normal llamarle carpetas en modo gráfico, pero en el antiguo ms-dos y en el terminal linux, se me hace raro llamarle carpetas.

CortoCircuito

#13 idem. Yo sigo resistiendo, me niego a llamarlas carpetas. 😂 👍

D

#13 Tan claro como la instrucción para listar el contenido de los mismos:

DIRectorio

R

#12 #13 lo de carpeta viene ya de la epoca de Mac Classic, no de Windows. Y no solo carpeta, sino que tenias la "Carpeta del sistema"

D

#13 Otro de esa epoca y que le pasa igual.

g

#6 C:\Linux p.ej.

A

#5 pero si creas un superroot estamos en las mismas

XrV

#8 bueno, lo que haces es delegar al root a una segunda posición. Eso se debería poder hacer con un usuario semiroot sin tener que tocar el kernel. No entiendo porque Linus ha aceptado el cambio, supongo que harà la vida más facil a algunos.

x

#5 pues no uses sudo. Cuando quieras hacer algo como root, lógate como root y sal al terminar.

D

#20 ¿No se supone que eso es todavía más peligroso?

x

#21 no si sales al terminar. Lo que es peligroso es administrar el ordenador con la misma contraseña con la que entras en la cuenta de usuario, quitas el salvapantallas, tal vez lees el correo... La contraseña de root es solo para administrar, y si un programa te la pide te tienes que mosquear. Pero para eso tienes que tener contraseña de root diferente a la que usas continuamente porque no eres root continuamente.

D

#22 gracias ¿Entonces es peor usar sudo?

x

#25 sí. Lo que importa no es el nombre del usuario, sino la contraseña, y con sudo usas la contraseña que usas para todo. Con "su -" usas una diferente que es solo para administrar.

D

#27 Pues ahora me has dejado descuadrado. Siempre pensé que sudo, además de poder darle el poder a un usuario para hacer administración, era más seguro que usar directamente a root. Gracias de nuevo.

x

#28 na. Además, en esto no todo el mundo piensa como yo. Los que descubrieron linux con Ubuntu prefieren el sudo, pero los de Ubuntu pusieron el sudo* para administrar para que el usuario novato no tuviera que pensar en cuándo es administrador y cuándo no.

* antes de eso se usaba para cosas muy concretas, como por ejemplo arrancar un servidor web de desarrollo en un puerto bajo el 1024 o cosas así. Muy acotadas.

D

#29 Yo aprendí con opencaldera, redhat 6 y luego mandrake. Ahora hace ya unos siete u ocho años que solo uso debian, pero igualmente no me había informado bien sobre sudo. Nunca me gustó nada que llevase el nombre *buntu

x

#30 yo parecido...

t

#29 Uhm... Tendría que hacer más memoria de la que puedo allocar, pero juraría que usaba sudo en Debian Potato, algunos años antes de probar un Ubuntu... de hecho mi memoria me dice que en más de un sitio, y hablo de libros, recomendaban sudo como método seguro para no olvidarte una sesión root abierta, o para no ejecutar sin querer un comando peligroso como root.

Pero ya te digo que no me fio de mi memoria, perfectamente podría estar mezclando épocas y la costumbre del sudo traerla desde algún Ubuntu...

U

#38 Tu memoria no te falla. sudo se ha usado desde siempre.

a

#20 no has entendido nada

anv

#2 Nada que ver. Esto se trata de evitar que se carguen módulos en el kernel después de que el sistema haya arrancado.
El root sigue existiendo para lo que se usa normalmente (instalar aplicaciones y configurar algunas cosas)

U

#2 Desgraciadamente, la forma Android de hacer las cosas (mucho más segura que la tradicional) todavía tardará tiempo en llegar a Ubuntu y otras distros.

Que un proceso tenga todos los privilegios es una Mala Idea. Además, es totalmente innecesario para el 99,9% de los usuarios. Incluso si eres del 0,1% restante (lo más probable es que no, aunque creas que sí), para que puedas hacer con tu aparato lo que quieras basta conque el bootloader (o su equivalente en un PC, el firmware UEFI) se pueda desbloquear. Desgraciadamente esto no se cumple en todos los aparatos Android, depende del fabricante, pero sí en los Nexus/Pixel de Google sí.

ctrl_alt_del

Pues nada, [DOMINIO]Administrador...

D

Windows también restringe el acceso a ciertos archivos y carpetas que se pueden acceder desde Linux. ¿Tendremos que usar Windows para acceder los archivos restringidos de Linux?, ¿se podrá hacer desde otro Linux?

anv

#15 Si te refieres a quitar el disco duro y ponerlo en otro equipo, obviamente tendrás acceso a lo que haya grabado en ese disco.

Pero no es el caso. Simplemente se trata de impedir la carga de nuevos módulos en el núcleo del sistema después de que haya arrancado.

csmNapster

Yo creía que el kernel Linux traía alguna función para esto, y más cuando los BSD ya tienen algo parecido desde hace décadas (securelevel).