Linux isn't perfect, nor is any other operating system kernel. Nor is any system software perfect. Any software is only as good as its most recent bug, or as good as its next bug. This is true of Linux too. Sometimes, bugs can really get you in trouble.
Buffer Overflows. Perhaps the most insidious type of software bug from a security standpoint is the infamous buffer overflow. A buffer overflow is a design problem caused by data that overfills a memory location and causes a program to behave unpredictably. Sometimes, such an overflow will cause the program to spawn a command shell with the same level of privilege that the program itself runs with. So, if a program is running as root (the highest level of system authority available), a buffer overflow in that program may cause the spontaneous creation of a``root shell'' to the person who overflows one of its buffers. This can be extremely dangerous to your system.
Perhaps most common security problems are caused by misconfiguration of system software, but the buffer overflow is the most serious software design problem that plagues system administrators the world over. Misconfiguration errors are operational errors, and they aren't the software creator's fault. Buffer overflows are the software creator's fault, and even the best programmers make mistakes. So your Linux system's integrity depends on your keeping it current with the latest fixes and patches for the bugs that inevitably are discovered.
Recent Discoveries. As mentioned earlier, the biggest risks are with system software that runs as root. When these programs break, they might spawn a root shell and allow a remote or local user to issue commands with root privileges. Several programs that run with high privilege on your system have been discovered in recent months. You'll notice that these are bugs in server software. Each of these are daemons that run with a high level of privilege on your system.
Named/bind. Named is the name of the server that handles your name lookups, which convert``dotted quad'' internet addresses--like 192.168.15.256--to addresses that humans can make something out of, like mailbox.myisp.com. Like all server software, named listens on ``ports'' which you could think of as TV channels in your cable to the Internet. The server waits and listens for certain requests on its name lookup channel (port), and when it hears a request, it answers it. Unless you have bind 8.2.2 or better, you could be vulnerable to an attack that exploits a weakness in this software. Your name server could be giving more information about your network than you want the outside world to know. (Have a look at http://www.isc.org/products/BIND.)
Imapd. Imapd is a mailserver with a relatively new and less robust protocol implementation. If you have to run it, search rootshell.org for all the imapd related security attack scripts available, and you might reconsider your need to run it. Most of these scripts are old, but all too many still work just fine today. For example, it's possible to crash imapd and leave shadow passwords in a core file. There are remote imapd exploits that will even get remote access by overwriting a buffer in imapd. There's a rather nasty one that became possible with imapd 4 that came with Pine 4.0 from University of Washington.
Syslogd. A non-root user can panic the linux kernel by use of the system logger command. You must set resource limits to the kernel in order to stop this attack.
Ssh. I seem to have stumbled across numerous exploits available in SSH (secure shell) over the last several years. One exploit allows a normal user to redirect privileged ports, so that he could intercept secure online sessions, for example. This first was discovered around August of 97 and has since been fixed. But about a year ago, an overflow in SSH 1.2.26's kerberos code was found. You want at least beyond this version of ssh.
Rpc.nfsd. The rpc daemons handle requests to mount and unmount file systems through protocols like NFS (network file system). Trouble is, this is a very old technology, and, like many old network tools, was never really built with security in mind.
Some versions of rpcbind allow an attacker to insert and delete entries without superuser status. There are scanners that look for vulnerable Linux rpc.mountd servers. In fact, there are more rpc scanners out there than you can shake a stick at. They will try to scour your network for all the information, and some can even get by port filters and scan internal subnets to get dumps of RPC services. Some implementations of rpc even allow remote attackers to get NFS file handles for mounted filesystems. Scary. The moral of this story is don't run RPC services on perimeter boxes, and when you do run RPC services, run only the latest versions of them.
So How Do I Sleep Now? Well, there are actually quite a lot more exploits out there than I've listed or alluded to. I haven't even listed all the popular categories of exploits. So, if you're in the Internet security business, you probably haven't been getting a great deal of sleep anyway. If you aren't in the Internet security business, you ought to know someone who is. The old axioms are 1) only run necessary daemons on your servers, 2) run your servers with as low a level of privilege as possible, and 3) keep your servers ultra simple. Just as network crackers are increasingly active, network security people are active too. There are new generations of logging, intrusion detection, port filtering, and related security tools becoming available all the time.
For example, Red Hat systems can run the ``Bastille Linux'' scripts to help harden and secure their systems. (See www.bastille-linux.org.) This scripts marches through your entire system searching for broken configuration files, bad permissions, poorly formed firewall rules or access tables, and gives you a list of things to fix. Newer generations of scripts will even change them as they go, giving you a detailed report of what was done. Take heart! There is hope after all!
Some of the sites below contain security info you can use. Again, these are only a few starting points. There are many, many more like this. You should probably subscribe to the BugTraq mailing list, since this is a popular forum discussing exploits of all types.
Some Resources: