3 ms·

why wouldn't it work? sudo -s works too. sudo su. sudo bash.

• klodolph 14y ago
  1) All sudo commands show up in the logs. You can put the logs on another server, possibly a server where only the head of IT has sudo privileges, possibly one that automatically replicates to other sites. Seeing a "sudo su", "sudo bash", or "sudo -s" in the logs could get you reprimanded, and if there's a security breach it could make you a suspect. 2) You can disable sudo -s, sudo su, and sudo bash. Maybe the people with root access only need to run a few commands and edit a few files as root, so you whitelist those. But as I mentioned, if they need to edit crontab you've probably given away the keys to the kingdom right there. There are more attack vectors you can enable without knowing about it and you've got a business to run, so you make a cost/benefit analysis -- it's always a trade-off between efficiency and security.
  • Evbn 14y ago
    Isn't 'sudo vi' already game over? :sp /bin/vi ... :wq
    • klodolph 14y ago
      > Isn't 'sudo vi' already game over? Yes, I wasn't very clear when I said the following... > Okay, so you're a good admin and disabled that. What I mean is that you disable "sudo vi" access, and allow "sudoedit" access. Suddenly you only have write access to certain files. But which files? These people need to administer the server, but at the same time you want to prevent them from creating a backdoor, or at least you want to know about it if they do. /etc/crontab is just an obvious example. Maybe you can get suborn a filter somewhere that runs as root, or poison the environment variables of a legitimate script.
• deleted 14y ago
  [deleted]