Linux expert Rick Moen upgraded his authoritative piece on viruses and Trojans in Linux two days ago.
IT SHOULD BE A MUST READ FOR ALL LINUX USERS ... ESPECIALLY NEWBIES...
One sentence summary: You aren't in Windows any more, Todo...
IT SHOULD BE A MUST READ FOR ALL LINUX USERS ... ESPECIALLY NEWBIES...
One sentence summary: You aren't in Windows any more, Todo...
*
V. In Summary:
There are real threats to Linux security. If you spend time looking for "Linux viruses" — which, by and large, can come at your system only if you get behind them and push — you might miss the real threats and not do something useful like studying your security profile and other measures.
And yes, some "virus" author could in principle, some day, in the very worst-case scenario — if he/she were able to find a remotely exploitable Linux kernel network-code flaw unknown to everyone else — unleash a devastating and rapid, automated, surprise attack that clobbers (compromises) within one hour a large percentage of, say, worldwide Internet-connected i386 Linux servers' TCP/IP stacks, and thus gains root control.
This would force all afflicted systems to be offline for a day to await the necessary patch and be rebuilt. That would be very annoying — but would hardly be unrecoverable. Moreover, I'll give very long odds against this or less-central failures happening, too — and lower ones for the same threat against practically every other OS.
Why? Some of the reasons were articulated nicely in (separate) analyses by Nick Petreley, Eric Raymond, and Karsten M. Self:
o System was designed for multiuser and networked operation from the ground up.
o System was designed to distrust and not rely (in the general case) on remote procedure calls (RPCs), especially not between hosts.
o System is profoundly modular, with the simplest, most generic possible interactions (often via pipes or textual interchange — even if then layered over sockets, etc.) between components (which can thus be individually changed, patched, upgraded, removed, or disabled as desired — without, in general, large interdependency consequences or cascade failures). Within that modular framework, functional substitutes exist and can be swapped in for almost all common security-relevant codebases. (E.g., if OpenSSH is having security problems, I can easily sidestep to LSH or any of several other SSH daemons. Ditto Web servers, ftp daemons, mail servers, etc. If need be, I can even change kernels.)
o System doesn't give software excessive privilege or easy paths to escalation. Components run with high privilege are kept as small and carefully checked as possible. Interacting components seldom even run as the same effective user ID, and thus are in a poor position to subvert one another's resources.
o As a result of the above, system state is highly transparent, lending itself to effective scrutiny and management via simple, well-understood tools (including ps, netstat, lsof, lslk, fuser, etc.).
For details, please see Petreley, Raymond, and Self's more-comprehensive write-ups.
Last modified: 2010-03-02
rick@linuxmafia.com
Copyright (C) 1995-2010 by Rick Moen. Verbatim copying, distribution, and display of this entire article (page) are permitted in any medium, provided this notice is preserved.
V. In Summary:
There are real threats to Linux security. If you spend time looking for "Linux viruses" — which, by and large, can come at your system only if you get behind them and push — you might miss the real threats and not do something useful like studying your security profile and other measures.
And yes, some "virus" author could in principle, some day, in the very worst-case scenario — if he/she were able to find a remotely exploitable Linux kernel network-code flaw unknown to everyone else — unleash a devastating and rapid, automated, surprise attack that clobbers (compromises) within one hour a large percentage of, say, worldwide Internet-connected i386 Linux servers' TCP/IP stacks, and thus gains root control.
This would force all afflicted systems to be offline for a day to await the necessary patch and be rebuilt. That would be very annoying — but would hardly be unrecoverable. Moreover, I'll give very long odds against this or less-central failures happening, too — and lower ones for the same threat against practically every other OS.
Why? Some of the reasons were articulated nicely in (separate) analyses by Nick Petreley, Eric Raymond, and Karsten M. Self:
o System was designed for multiuser and networked operation from the ground up.
o System was designed to distrust and not rely (in the general case) on remote procedure calls (RPCs), especially not between hosts.
o System is profoundly modular, with the simplest, most generic possible interactions (often via pipes or textual interchange — even if then layered over sockets, etc.) between components (which can thus be individually changed, patched, upgraded, removed, or disabled as desired — without, in general, large interdependency consequences or cascade failures). Within that modular framework, functional substitutes exist and can be swapped in for almost all common security-relevant codebases. (E.g., if OpenSSH is having security problems, I can easily sidestep to LSH or any of several other SSH daemons. Ditto Web servers, ftp daemons, mail servers, etc. If need be, I can even change kernels.)
o System doesn't give software excessive privilege or easy paths to escalation. Components run with high privilege are kept as small and carefully checked as possible. Interacting components seldom even run as the same effective user ID, and thus are in a poor position to subvert one another's resources.
o As a result of the above, system state is highly transparent, lending itself to effective scrutiny and management via simple, well-understood tools (including ps, netstat, lsof, lslk, fuser, etc.).
For details, please see Petreley, Raymond, and Self's more-comprehensive write-ups.
Last modified: 2010-03-02
rick@linuxmafia.com
Copyright (C) 1995-2010 by Rick Moen. Verbatim copying, distribution, and display of this entire article (page) are permitted in any medium, provided this notice is preserved.
Comment