4 ms·

"Maybe he was editing a file in sudo with vi and ran ":! bash"" Ah, yes, works on a default Ubuntu desktop install provided you have vim installed (not the usu

"Maybe he was editing a file in sudo with vi and ran ":! bash"" Ah, yes, works on a default Ubuntu desktop install provided you have vim installed (not the usual tiny-vim package that uses nano for visudo editing).

iso8859-1 14y ago
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]
nitrogen 14y ago
When in elementary school I would use a similar technique to get a command line: Word Perfect for DOS could launch command.com.

iso8859-1 14y ago

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]

nitrogen 14y ago

When in elementary school I would use a similar technique to get a command line: Word Perfect for DOS could launch command.com.