No, en realidad es una buena práctica de seguridad sudo cuando necesita privilegios de nivel superior. Esta es la razón por la que la mayoría de las distribuciones prohíben el inicio de sesión predeterminado y en realidad lo obligan a sudo suhacerlo en lugar de simplemente escribir su: quieren alentarlo a usar sudo para sus beneficios de seguridad. Hay algunas razones por las cuales:
Revisión de cuentas. Cuando sudo, el sistema mantiene un registro de quién sudo y el comando que ejecutaron. Esto agrega una gran cantidad de información forense cuando necesita regresar y descubrir qué sucedió: asignar culpas, detectar actividades nefastas o simplemente para solucionar problemas (¿qué demonios sucedió anoche a las 7PM antes de que este servidor se fuera de servicio?)
Sudo gobierna. El hecho de que un usuario necesite ejecutar algo con privilegios escalados no significa que deba ejecutar todo con privilegios escalados. Usar su o agregar un usuario a la rueda le permite a un usuario hacer todo . Sin embargo, con sudo es posible especificar lo que los usuarios pueden y no pueden hacer usando los Alias de comando que permiten el uso de comodines, lo que permite reglas flexibles que otorgan privilegios a los usuarios para usar algunos comandos, pero no otros.
Endurecimiento. Es posible deshabilitar root. Como en, para todos los efectos, no existe y solo es útil / utilizable en modo de usuario único, lo que requiere un reinicio de un servidor (y la única razón por la que esto está permitido es para la recuperación de la contraseña). sudo suYa no funciona. Esto se hace configurando el shell de root en / bin / nologin. que es una excelente manera de prevenir muchas vulnerabilidades de escalada de raíz. Esto, por supuesto, supone que está utilizando correctamente la viñeta anterior (y aún puede otorgarle a un usuario administrador específico todos los permisos, aunque esto socavará su postura de seguridad).
Estas cosas son, por supuesto, solo una parte de su modelo de seguridad. Por ejemplo, a menos que no tenga usuarios con privilegios administrativos completos (y a veces incluso entonces) su usuario podrá (probablemente puede) eliminar registros e historial, a menos que use un servidor de registro y syslog para enviar registros fuera de la caja. Entonces no hay forma de volver a poner a ese gato en la bolsa. Por supuesto, si usa una estructura de directorio de autenticación central, esto vuelve a entrar en juego: si comprometo una cuenta, se ve comprometida en todos los servidores de la organización, incluido probablemente su servidor de registro.
En resumen, la seguridad es complicada, pero sudo es una gran herramienta para diseñar un entorno seguro y más personas deberían usarlo en toda su extensión.
sudo: "sudo: lo siento, debes tener un tty para ejecutar sudo"sshla-topción. O convencer a sudo de que no lo necesite como unix.stackexchange.com/questions/122616/…sudocomo lo demuestra el enlace?Defaults requiretty)