From: Ulrich Weigand <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security
Date: Sun, 10 Nov 2002 17:55:53 +0100
Well, Linux has capabilities nowadays, but they aren't much used
in your typical distribution. There are also patches that implement
a variety of more elaboate authorisation schemes like mandatory
access control (see e.g. the NSA's SELinux patch or the RSBAC
project).
You are right, but most of these schemes are based on user access to
objects, where the authorisation is based on the user.
This is different from the operating model, where programs are
compartimentalised in their execution environment such that they only have
access to what is strictly needed.
The latter is an integrity issue, whereas the former is an authorisation
issue. I am mainly concerned about the integrity issue, as that is the
area that I think is the weakest part, and the part where most
vulnerabilities reside that can be exploited (other then configuration
issues).
But even so, I think the confusions stem from another source.
The question really is, what entity is the 'holder' of any
authorisation? The various schemes (uid-based rights,
set-uid, capabilities, MAC, ...) are all different in the
details of how you acquire any particular authorization,
but once you got it, the authority rests in the *process*.
This means that either the process has the right to perform
any particular act or it doesn't. But at no place does
this right depend on just what code within its address
space the process is currently executing.
I think that that is exactly my point, once a process is running, there is
nothing left that restricts any program (ie piece of code) to do anything to
any of the resources it has access to, including code/data of other programs
within the same process (either on purpose or inadvertendly).
What you call a 'program in the shared lib' is a concept
that is fundamentally alien to Unix. A process is a process;
it executes code from within its address space. If the code
was loaded from a shared library, it is still executed as part
of this process; it has no 'identity' of its own.
I'm really not sure how this fundamental concept could be
changed so that the result still somewhat resembles Unix ...
I am not sure that one would run away from the concept of unix. One can
easily (in concept anyway) add more spaces to one process, separate spaces
for code, stack and data for example.
Similarly, shared libs could reside in their own space, one would need a
different linkage mechanism, but it can effectively been done. Such a
linkage mechanism can also reduce/extend the program authority (based on key
masks for example, and what spaces are accesible from the shared lib, and to
what extent). The same logic can be applied to different code segments
within one process. The (initial) linkage would need some supervisor
assistance in order to setup/verify program authorisations.
Nevertheless, something like what you describe can of course
be modelled in Unix, but you need to use multiple processes
to represent the different authorization domains; these
processes can then use shared memory and other inter-process
communication facilities to interact in a way that precisely
implements the various privileges you describe.
I would actually like to see those mechanisms applicable to one process,
inter process communication is a different issue. Surely, one can do a lot
of message passing between processes in order to isolate different program
segments, but that is not quite what I see as an issue here, or even a
solution.
What I still have not seen in this whole discussion is even
*if* one were to implement some sort of authorization domains
on a finer granularity than processes, and even if this would
all work out somehow, what *benefit* this would bring over and
above what is already now possible in Unix using multiple
process as just described ...
If one where to implement any sort of facility that compartimentalises
programs and code fragments in their execution environment, then that could
greatly reduce the damage a potential exploit or programming error could do.
Jan Jaeger.
_________________________________________________________________
MSN Zoeken, voor duidelijke zoekresultaten!
http://search.msn.nl/worldwide.asp
