Jan Jaeger wrote: >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.
Yes, but the problem remains that you need to have the kernel aware of those sub-process authorization domains, so that it will be able to properly allow or reject syscall actions depending on what part of the process performed the syscall. So there's at least one fundamentally new concept needed, and I'm not sure what exactly the proper semantics of this concept should be. As a secondary consideration you need to make sure that user space cannot undermine this new authorization domain scheme; this means that code running in one domain cannot modifiy memory belonging to another one, but also e.g. that you cannot randomly call into another domain but only at defined entry points. (This item is where hardware support is helpful.) Obviously, you'd also need to use different stacks for code running in different domains. Finally, for this to make any sense the various pieces of code running in different domains would need to treat all input received from other domains as potentially hostile and fully validate it (like the kernel needs to validate all syscall arguments to avoid being tricked into doing something bad by hostile user space). The same applies for data residing in 'shared' memory (i.e. memory that is accessible from multiple domains) -- everything there must also be validated before being used. >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 don't understand is why this is all that different. Seeing as how you need to be very careful with any input received from another domain, cross-domain calls would need to be carefully implemented and all arguments would need to undergo validation, this means that you'd structure those interfaces quite similar to inter-process interfaces in any case. >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. Sure, but my point was what additional advantages authorization domains within a single process have over just using multiple processes as domains. If the former would allow existing programs to be made more secure without major changes, I could see the point. But I don't believe this to be the case, in fact I think that changing a program to exploit these domains would need at least as much effort as changing it to a multi-process regime. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
