The flaws of the Unix safety model have been known for a long time. However, modern Unices like Linux are easily extended. A wealth of security-related patches, extensions and enhancements have been created for Linux. And the Linux kernel itself underwent a number of security related improvements like support for POSIX capabilities.
Since most Unix (Linux) computers are linked to a public network nowadays -- for example to the Internet -- even more security enhancements are necessary to protect the system. Some examples include:
'Linux capabilities' allow finer grained distribution of 'root' rights. Instead of having to grant or deny all rights, the regular 'root' rights are split up and can be granted individually to a program or process. There are not many programs yet that are capable of handling these capabilities[1].
A number of Linux filesystems allow setting of extra permission flags, like 'open for append'. Check out the chattr manual pages. Alas, 'root' is still able to revoke these rights at will. Some versions of the kernel do not support validation of these attributes.
Toolsets like 'bastille' (http://www.bastille-linux.org) will help closing many commonly misused security holes. I wholeheartedly recommend its use. However, none of the granularity problems are solved, nor is the omnipotence of 'root' challenged. Some hardening toolsets are only available for a limited number of distributions.
Intrusion detectiontools like 'tripwire' (http://www.tripwire.org) help in finding unintended changes on your system. However the aforementioned problems are not tackled at all. Intrusion detection is very useful but does not do anything to protect your system.
Well known programs like tcpd help to prevent unwanted network access to your system. Kernel mechanisms and accompanying configuration software like iptables and ipchains are very useful and can enhance your security significantly. But once someone gains access to your system, either legally or not, the old security related problems roar their ugly heads again.
Sometimes daemons or other untrusted processes are run from within a chroot jail. This prevents an intruder who employs a bug or backdoor within the daemon from doing too much damage on your system, but he or she still can do damage within the chrooted jail. And if this happens to be your ftp server, and the intruder succeeds in attaching worms or virusses to files intended for download, a lot of harm can be done in your name. And of course, the protection is limited to the chrooted daemon. Other processes may still threaten your security. The 'root' user is still able to access everything on your system.
One of the better ways to prevent someone to read your data is to encrypt it. Encryption adds the benefit of preventing someone to steal one of your backup tapes and read confidential data from it. But to be able to read your data, you need to decrypt it. And since root also is allowed to connect to your processes (for example using 'strace') chances are that 'root' can determine the password/passphrase you use to encrypt your private key. Also, 'root' is able to destroy your data by simply altering it or removing it.
Configurationtools like PIKT or cfengine assist with the configuration of conventional system parameters. They will check your system and correct flaws they find. But they also may require a process to run as 'root' to enable it to (re)configure your system. A system that can assist you in keeping your system well-configured is indeed very nice to have, but the core problems are not solved by these programs.
| [1] | Version 1.2.0 of RSBAC supports Linux capabilities. |