4 ms·

Some admins allow only certain command to be executed with sudo vs root can execute anything with root.

geofft 9y ago
I have never seen anyone implement such a policy for sysadmins that actually prevents an attacker from running arbitrary commands. As soon as you permit running e.g. vi on some file, you can just shell out from vi. Or if you can sudo apt-get install, you can downgrade a package to a vulnerable version and then exploit it. Or if you can sudo tcpdump, you can write a dump file to /etc/cron.d and send a valid cron command surrounded by newlines over the network. Or lots of other things. sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.
- skissane 9y ago
  10+ years ago I was setting up a new web server, Apache running on a Linux box. I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team. I asked for root access (via sudo) so I could do stuff like restart Apache. The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands. So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root. I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it. So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache. When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it. When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.
  - cosarara97 9y ago
    Shouldn't apache have been running under the "apache" user instead of root?
    - spc476 9y ago
      By default, only root can bind to ports 80 and 443. You can change this policy, but that's considered unsecure because then any program can bind to the so called "privileged ports."
      - Godel_unicode 9y ago
        You can be more specific than that and allow only a specific user/program to bind a specific privileged port. This is accomplished with a combination of SELinux and the capabilities API in 2.6.24 and newer.
        d4rti 9y ago
        Or alternatively, rewrite incoming traffic with iptables, https://www.cyberciti.biz/faq/linux-port-redirection-with-iptables/ https://www.cyberciti.biz/faq/linux-port-redirection-with-ip...
        geofft 9y ago
        Even if you do that, I think Apache still starts as root to do things like open SSL certificates and log files (and logging configuration is the thing exploited here). Is there a common config - e.g. an initscript / systemd unit on an SELinux distro - that starts Apache as a dedicated user? I know Apache supports being started as an unprivileged user (I do this myself a lot when I need something a little more featureful than SimpleHTTPServer) but my impression was that that's not very common for production deployments.
    - tscs37 9y ago
      When the binary in question is setuid, it doesn't matter what user runs it. It'll run as the owner and group of the file itself.
- TheAceOfHearts 9y ago
  On macOS an administrator (someone in the admin group) cannot create, delete, or move files in the system domain. That makes it harder to completely fuck up the computer, but as you say it won't really stop an attacker from running almost any arbitrary command.
xorcist 9y ago
Hopefully all admins does that. Never allow a user to run any command if you intend for them to run just one. SSH public keys have the exact same feature however. Look at "command=" under "Authorized Keys File Format" in the man page. This is a good idea for batch jobs that uses SSH to execute on remote machines. With SSH keys you even have the option of limiting keys not just to certain commands but to certain IP addresses. By limiting the SSH keys you also don't have to give your keys access to an unprivileged shell where you don't need it.

I have never seen anyone implement such a policy for sysadmins that actually prevents an attacker from running arbitrary commands. As soon as you permit running e.g. vi on some file, you can just shell out from vi. Or if you can sudo apt-get install, you can downgrade a package to a vulnerable version and then exploit it. Or if you can sudo tcpdump, you can write a dump file to /etc/cron.d and send a valid cron command surrounded by newlines over the network. Or lots of other things. sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.

skissane 9y ago
10+ years ago I was setting up a new web server, Apache running on a Linux box. I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team. I asked for root access (via sudo) so I could do stuff like restart Apache. The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands. So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root. I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it. So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache. When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it. When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.
- cosarara97 9y ago
  Shouldn't apache have been running under the "apache" user instead of root?
  - spc476 9y ago
    By default, only root can bind to ports 80 and 443. You can change this policy, but that's considered unsecure because then any program can bind to the so called "privileged ports."
    - Godel_unicode 9y ago
      You can be more specific than that and allow only a specific user/program to bind a specific privileged port. This is accomplished with a combination of SELinux and the capabilities API in 2.6.24 and newer.
      - d4rti 9y ago
        Or alternatively, rewrite incoming traffic with iptables, https://www.cyberciti.biz/faq/linux-port-redirection-with-iptables/ https://www.cyberciti.biz/faq/linux-port-redirection-with-ip...
      - geofft 9y ago
        Even if you do that, I think Apache still starts as root to do things like open SSL certificates and log files (and logging configuration is the thing exploited here). Is there a common config - e.g. an initscript / systemd unit on an SELinux distro - that starts Apache as a dedicated user? I know Apache supports being started as an unprivileged user (I do this myself a lot when I need something a little more featureful than SimpleHTTPServer) but my impression was that that's not very common for production deployments.
  - tscs37 9y ago
    When the binary in question is setuid, it doesn't matter what user runs it. It'll run as the owner and group of the file itself.
TheAceOfHearts 9y ago
On macOS an administrator (someone in the admin group) cannot create, delete, or move files in the system domain. That makes it harder to completely fuck up the computer, but as you say it won't really stop an attacker from running almost any arbitrary command.

xorcist 9y ago

Hopefully all admins does that. Never allow a user to run any command if you intend for them to run just one. SSH public keys have the exact same feature however. Look at "command=" under "Authorized Keys File Format" in the man page. This is a good idea for batch jobs that uses SSH to execute on remote machines. With SSH keys you even have the option of limiting keys not just to certain commands but to certain IP addresses. By limiting the SSH keys you also don't have to give your keys access to an unprivileged shell where you don't need it.