La seguridad siempre se trata de hacer compensaciones. Al igual que el servidor proverbial que se encuentra en un lugar seguro, desconectado, en el fondo del océano, rootsería más seguro si no hubiera forma de acceder a él.
Los ataques LD_PRELOAD y PATH como los que usted describe asumen que ya hay un atacante con acceso a su cuenta, o al menos a sus archivos de puntos. Sudo no protege contra las que muy bien a todos - si tienen su contraseña, después de todo, no hay necesidad de tratar de engañar a usted para más adelante ... sólo se puede utilizar sudo ahora .
Es importante tener en cuenta para qué se diseñó originalmente Sudo: delegación de comandos específicos (como aquellos para administrar impresoras) a "subadministradores" (tal vez estudiantes graduados en un laboratorio) sin entregar la raíz por completo. Usar sudo para hacer todo es el uso más común que veo ahora, pero no es necesariamente el problema que el programa estaba destinado a resolver (de ahí la sintaxis ridículamente complicada del archivo de configuración).
Pero, sudo-para-sin restricciones de la raíz hace frente a otro problema de seguridad: gestión de las contraseñas de root. En muchas organizaciones, estos tienden a pasarse como dulces, se escriben en pizarras y se dejan para siempre. Eso deja una gran vulnerabilidad, ya que revocar o cambiar el acceso se convierte en un gran número de producción. Incluso hacer un seguimiento de qué máquina tiene qué contraseña es un desafío, y mucho menos rastrear quién sabe cuál.
Recuerde que la mayoría de los "delitos cibernéticos" provienen del interior. Con la situación de la contraseña de root descrita, es difícil rastrear quién hizo qué, algo que sudo con el registro remoto trata bastante bien.
En su sistema doméstico, creo que es más una cuestión de conveniencia de no tener que recordar dos contraseñas. Es probable que muchas personas simplemente los configuraran para que fueran iguales, o peor, al principio para que fueran iguales y luego dejaran de sincronizarse, dejando que la contraseña de root se pudriera.
El uso de contraseñas en absoluto para SSH es peligroso, ya que la contraseña detectores de demonios ssh con troyanos se puso en marcha en algo así como el 90% de los compromisos del sistema del mundo real que he visto. Es mucho mejor usar claves SSH, y este también puede ser un sistema viable para acceso raíz remoto.
Pero el problema es que ahora ha pasado de la administración de contraseñas a la administración de claves, y las claves ssh no son realmente muy manejables. No hay forma de restringir las copias, y si alguien hace una copia, tienen todos los intentos que desean para forzar la frase de contraseña. Puede hacer una política que diga que las claves deben almacenarse en dispositivos extraíbles y solo montarse cuando sea necesario, pero no hay forma de hacer cumplir eso, y ahora ha introducido la posibilidad de que un dispositivo extraíble se pierda o sea robado.
La mayor seguridad vendrá a través de claves de una sola vez o tokens criptográficos basados en tiempo / contador. Esto se puede hacer en software, pero el hardware resistente a la manipulación es aún mejor. En el mundo de código abierto, está WiKiD , YubiKey o LinOTP , y por supuesto también está el SecurID RSA de peso pesado patentado . Si está en una organización de mediana a grande, o incluso en una pequeña que se preocupa por la seguridad, le recomiendo que busque uno de estos enfoques para el acceso administrativo.
Sin embargo, probablemente sea excesivo para el hogar, donde realmente no tiene los problemas de administración, siempre que siga prácticas de seguridad sensatas.