Jan Jaeger wrote: >I think that the real issue here is that Linux (or unix in general) does has >litte to offer with regard to program capabilities (ref keykos/eros micro >kernel designs). Under Linux, (acl based) one basically has all the >authorisations of the user under which one is running. (setuid programs >being the only program capability). There is no concept of different >program authorisation levels (the things that in S/390 PC/PT, BSA, subspaces >etc were designed for)
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). 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. >An implementation of such a scheme could be that program b (which was called >by program a), runs with storage key x, and once program b calls a program >in a shared lib then the program in the shared lib will be running with >storage key y, but still has access to data areas from program b (with >storage key x), but there no capabiliy anymore to reference to anything from >program a. Upon return to program b, there is no capability anymore to >reference anything from the shared lib, but data from program a has >reappeared visible. 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 ... 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. 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 ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
