Unix was not created with security in mind[1]. During its first 20 years Unix was mainly used by computer professionals, and computer crime was a rarity. The need to exchange information prevailed over the need to protect it and so the need for more than just a rudimentary security system was often absent[2]. The popular belief that (any) Unix is a 'secure operating system' may well stem from the fact that mainstream operating systems that were introduced later proved to be notoriously unsafe.
On a Unix (Linux) system access to system objects like memory and files is granted to processes. These processes are initiated by (or on behalf of) system users. A process typically loads a program to perform its tasks.
A task can be performed safely if the process has just enough rights. If a process has more rights its program may gain access to classified system objects. By clever use of known bugs or backdoors in the program code a cracker could even manipulate classified objects, which in turn may result in loss of data and performance penalties.
To prevent this, some kind of system needs to be put in place that gives processes "just enough" rights. On an average Unix system this defaults to a crude mechanism: Unix file permissions. This model lets the kernel decide whether or not a process may access a system object (memory, device, disk etc.) based upon persistent lists of permissions, that are part of the filesystem. The kernel checks these lists to determine if access should be granted or denied.
This only provides a crude granularity: for files we have lists that can specify access for a user, a predefined group of users (in which everybody has exactly the same rights) and "everybody else". We only can specify read-, write- and execute permissions. That's it. If you want to grant one user reading rights, another user reading and writing rights and yet another user execution rights - and everybody else no rights at all - you're stuck. You are forced to solve this at the application level.
The low granularity of this security model often causes Unix processes to have too many rights. If more granularity is needed one has to resort to adding security related code into the program source code. But what if you do not have access to the source code? Or what if the programmer made a mistake? A running process can be manipulated i.e., by employing some bug. The situation is worsened by the fact that Unix permissions are often not properly configured.
Then there is the system user named 'root'. It's a very remarkable user: any process that acts on behalf of that user can in effect do anything it wants, including manipulating system data to mask its actions. The obvious solution - do not grant 'root' privileges to processes anymore - can not be implemented, since access to many system objects depends on root rights. For example access to one of the privileged ports, let's say port 80. The http daemon that uses that port is required to have root rights. Properly written daemons will revoke that right as soon as possible, but that's not mandatory and can not be enforced by the kernel. As far as the kernel is considered any process that is started on behalf or 'root' can do whatever it wants.
But Joe Average User may also inherit too many rights. On a standard Unix system an average user is allowed to create files and can allow other users to gain access to them. "Of course" you may say. But let's assume Joe is a human resource manager whose files are highly confidential. On many instances the Joe's in this world are not even aware of file permissions. The default permissions well may allow other users in his group to read his files. Anyway, on a Unix system at least 'root' will always be able to read and alter his files.
Allowing Joe to access his own files seems fair enough. But the standard Unix security model assumes that it is Joe who is allowed to grant access to this file to other users too. That assumption is often incorrect. And when we are considering the fierce European privacy laws and regulations, the Unix security model is seriously flawed to say the least.
| [1] | More information about standard Unix security can be found at http://secinf.net/info/unix/usec/unix_information.htm |
| [2] | Not withstanding the fact that even in the late 80's and early 90's of the last century secure Unices have been available that satisfied the (now superfluous) C2/B1 " Orangebook" levels. |