2 ms·
I would recommend against using sudo su -, esp if you have <user> ALL=(ALL) NOPASSWD: ALL or such constructs in your /etc/sudoers file that exempt password requ
by ppierald 14y ago
I would recommend against using sudo su -, esp if you have <user> ALL=(ALL) NOPASSWD: ALL or such constructs in your /etc/sudoers file that exempt password requirements from executing sudo commands.
1. su gives you a root shell. Principle of least privilege dictates you should executes the fewest commands as root as required, not all commands as root because you need one.
2. sudo su - loses auditability of who executed what/when. All we know is that someone got a sudo shell at some point. When the forensics guys come along post-breach, you won't have a lot of good info to give them.
3. Loss of a shell (via command injection on a web form) may allow remote Command-and-Control of your machine.
If you need a cron or other headless process (daemons, etc.) then use NOPASSWD in conjunction with a whitelisted set of commands (not /bin/bash) to be executed.
If you need an operator to execute a command as a specific user, then use sudo -u <user> <cmd>. Even if you allow ALL commands, at least your audit logs will know what/when the command was executed.
With all powerful commands comes the responsibility of understanding how to use them safely and what the possible repercussions are.
- mverwijs 14y ago4. And if you need to do anything extensive as root on a any machine, you might want to consider doing it with a configuration management system (puppet, chef, ansible).
- rlpb 14y agoIn production, yes. For debugging on a test machine, or during a post-mortem, it's just inconvenient not to. If the majority of your time is spent in the shell of a production machine, you're doing something wrong.