4 ms·

I do agree with your larger point that building your own here is undesirable, however the web server wouldn't have to have root by using IPC or other kinds of t

by WayneDB 14y ago

I do agree with your larger point that building your own here is undesirable, however the web server wouldn't have to have root by using IPC or other kinds of tricks. In any case, wouldn't it be even more secure if the server just pushed stats outwards (syslog anyone?) instead of needing to accept any kind of commands via SSH/HTTP/S or otherwise?

tptacek 14y ago
I am at a total loss for how any of this would require root access. I'm not sure any component of the system online or offline would need root; I'm absolutely certain the web app wouldn't. You don't need IPC tricks. I'd be less comfortable with the contraption that pushes stats out from the hosts. I don't agree that it would be more secure. Virtually any system you could imagine to solve this probably would almost by mathematical necessity be more secure than giving out a root SSH login, which is the funny thing about this thread.
- dllthomas 14y ago
  Mathematically, giving root login to person X is never more secure against person X than any other interaction with person X. I think the idea was regarding other people. With SSH, what you are exposing to those who lack the key is SSH, which is well hardened. If you set up a web service naively and run it as root, you have a weaker surface more exposed in exchange for more security against a mostly trusted party (who already has physical access). Of course, I'm not sure what kind of statistics can't be gathered by anyone but root; even if there are some (and there probably are in some configurations), I don't see why they couldn't be polled by root in a cronjob and dumped in a log file that's readable by a (specific, if you care) non-root user and fetched over SSH by that non-root user, &c. So, on the whole, I agree that there's no reason to give out root; but it's not a crazy notion that there are things worse than giving root to person A, with respect to your security against person B.
  - tptacek 14y ago
    Accidentally revealing server stats because of a bug handling a trivial authentication token is less of a big deal than giving a third party root shell access to your server, is my point.
    - dllthomas 14y ago
      But a bug in a web-server running as root might lead to privileged execution of arbitrary code. It's certainly true that a bug in the authentication code that incorrectly grants access is of substantially less severity than a leak or abuse of root key/password.
      - tptacek 14y ago
        Obviously you have to compare the likelihood of remote code execution in nginx/apache to that of ssh. Nginx is much, much simpler than OpenSSH. And, obviously, giving a third party remote root SSH access to your server already is a glaring vulnerability.
        dllthomas 14y ago
        The nginx package on Debian has more LOC than the openssh-server package. Apache, of course, is huge. This doesn't map perfectly onto complexity, but gives some indication that "much, much simpler" may not be entirely accurate. Moreover, the default SSH setup gives you everything you need for the (still undesirable) current setup, and is almost certainly running regardless. The default nginx install does not - you have to tweak setup to lock it down and add stuff to actually fetch the content, and since that (we have stipulated) has to be done as a privileged user there is room for error. Again, giving a root login key to OVH means no security against OVH, and relying on their securing the key. I agree that this is a bad idea. Depending on the amount you trust OVH and their security, it may be more secure against people other than OVH than certain specific alternatives (perhaps all the alternatives if you artificially constrain yourself into running a single process as root that talks to the outside).

by WayneDB 14y ago

tptacek 14y ago

I am at a total loss for how any of this would require root access. I'm not sure any component of the system online or offline would need root; I'm absolutely certain the web app wouldn't. You don't need IPC tricks. I'd be less comfortable with the contraption that pushes stats out from the hosts. I don't agree that it would be more secure. Virtually any system you could imagine to solve this probably would almost by mathematical necessity be more secure than giving out a root SSH login, which is the funny thing about this thread.

dllthomas 14y ago
Mathematically, giving root login to person X is never more secure against person X than any other interaction with person X. I think the idea was regarding other people. With SSH, what you are exposing to those who lack the key is SSH, which is well hardened. If you set up a web service naively and run it as root, you have a weaker surface more exposed in exchange for more security against a mostly trusted party (who already has physical access). Of course, I'm not sure what kind of statistics can't be gathered by anyone but root; even if there are some (and there probably are in some configurations), I don't see why they couldn't be polled by root in a cronjob and dumped in a log file that's readable by a (specific, if you care) non-root user and fetched over SSH by that non-root user, &c. So, on the whole, I agree that there's no reason to give out root; but it's not a crazy notion that there are things worse than giving root to person A, with respect to your security against person B.
- tptacek 14y ago
  Accidentally revealing server stats because of a bug handling a trivial authentication token is less of a big deal than giving a third party root shell access to your server, is my point.
  - dllthomas 14y ago
    But a bug in a web-server running as root might lead to privileged execution of arbitrary code. It's certainly true that a bug in the authentication code that incorrectly grants access is of substantially less severity than a leak or abuse of root key/password.
    - tptacek 14y ago
      Obviously you have to compare the likelihood of remote code execution in nginx/apache to that of ssh. Nginx is much, much simpler than OpenSSH. And, obviously, giving a third party remote root SSH access to your server already is a glaring vulnerability.
      - dllthomas 14y ago
        The nginx package on Debian has more LOC than the openssh-server package. Apache, of course, is huge. This doesn't map perfectly onto complexity, but gives some indication that "much, much simpler" may not be entirely accurate. Moreover, the default SSH setup gives you everything you need for the (still undesirable) current setup, and is almost certainly running regardless. The default nginx install does not - you have to tweak setup to lock it down and add stuff to actually fetch the content, and since that (we have stipulated) has to be done as a privileged user there is room for error. Again, giving a root login key to OVH means no security against OVH, and relying on their securing the key. I agree that this is a bad idea. Depending on the amount you trust OVH and their security, it may be more secure against people other than OVH than certain specific alternatives (perhaps all the alternatives if you artificially constrain yourself into running a single process as root that talks to the outside).