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/