Comment So what is the solution? (Score 2, Interesting) 592
Really, I look at a situation like this and, rather than lament about the sorry state of the software involved, I really just want to know how to make it not happen. With UNIX systems, this shouldn't be an impossibility - right off the bat many people have said "don't be root to install",which does stop one point of failure in the process, but it doesn't solve the problem of _running_ the application as root.
Some solutions come to mind for things that you should be doing anyway (firewall traffic on ports not being officially served by a system; make /bin binaries immutable), but these only make it so that the actions taken by the virus fail (relatively) silently. No big klaxons going off to tell the admin that a program is misbehaving as root.
Is there any sort of system-wide watchdog that can be put in place to monitor programs and catch actions that are outside the scope of its auspice? I think chroot can be used in a manner somewhat consistent with this idea, but not without resulting in some serious systemwide design complexity if you want to do it right. Any other thoughts?
And might this be an arguement for a Security Levels sort of system whereby things like "remove the immutable flag from /bin/bash" is made impossible without a reboot even for root, a la BSD?
Some solutions come to mind for things that you should be doing anyway (firewall traffic on ports not being officially served by a system; make
Is there any sort of system-wide watchdog that can be put in place to monitor programs and catch actions that are outside the scope of its auspice? I think chroot can be used in a manner somewhat consistent with this idea, but not without resulting in some serious systemwide design complexity if you want to do it right. Any other thoughts?
And might this be an arguement for a Security Levels sort of system whereby things like "remove the immutable flag from