Messages in this thread | | | Date | Wed, 27 Jan 1999 02:22:49 +0100 | From | Andrej Presern <> | Subject | Re: User vs. Kernel (was: To be smug, or not to be smug, that is , the question) |
| |
david parsons wrote: > > In article <linux.kernel.36AC84C7.26595942@luz.fe.uni-lj.si>, > Andrej Presern <andrejp@luz.fe.uni-lj.si> wrote: > >david parsons wrote: > >> One of the nice strengths of Unix is that it's basically an ad-hoc > >> system, blissfully free of some of the worst excesses of industry and > >> academia. > > > >One of the ugly weaknesses of Unix is that because it's basically an ad > >hoc system, it suffers from numerous, overly complex, inefficient and > >often inadequate security mechanisms (which themselves are ad hoc > >answers to security problems with other ad hoc solutions). > > If you're talking kernel security, I'll have to ask you to detail > these security problems. If you're talking _application_ security, > that's not a problem of the kernel (and can be dealt with by the > simple expedient of spending a few man years writing your own > userland.)
Well, actually, I had both in mind. The kernel because it implements the basic security mechanisms, and the user mode applications because they are defined by the kernel exported APIs. You can't separate that.
When I was refering to numerous and overly complex security mechanisms, I was thinking about chmod(), chown(), chroot(), capability lists support functions, chattr, secure level stuff, tcp wrappers, firewalls and so on. I'd say that's pretty numerous. As for complexity, each of those mechanisms tries to solve only a part of the security problem and does so through a different interface. And more often than not these mechanisms need to be combined to get a secure operating environment, which is not always trivial, especially for a novice and sometimes even for an expert user. Furthermore, few of these mechanisms naturally provide security - instead, one often has to make explicit privilege arrangements to share the data in a secure fashion with a fellow coworker (if such an arrangement is possible at all).
Despite the number of security mechanisms, it is still quite difficult (if not impossible) to prevent two programs running under the same username to have access to all of the user's files, and more, to all other user's privileges as well. This has been partially (another ad hoc solution) remedied in respect to kernel privileges with the introduction of capability lists, but the problem of userspace remains. The granularity of the system privileges also remains a problem, as can be seen from various requests for the extension of the capability list to include more fine grain access control.
As for efficiency, the basic security taxonomy happens to be: in order to have more fine grain security, one has to spend more resources checking various privileges and conditions thus being forced to make a tradeoff between security and performance.
Considering the above, I'd hardly call Linux security mechanisms anything else than numerous, overly complex, inefficient and often inadequate. And the reason for them being the way they are is that they were more or less ad hoc solutions to multiplying security problems that were not taken into account by the original UNIX designers.
> ____ > david parsons \bi/ I prefer working code to theoretical masterworks. > \/
So do I. But preceeding the working code are the recognition and the acknowledgement that there is a problem that needs to be solved (meaning: 'Unix security is perfect' does not help).
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |