Full disclosure alert: David and I have worked together on pulling together some stronger protection profiles.
On Sun, 2002-11-03 at 20:28, David Chizmadia wrote: > The fundamental security assurance problem is usually not > with the basic OS features: i.e., scheduling and process, > memory, and storage management. Instead, the evaluations > choke on the networking facilities! It would generally be > necessary to completely redesign the networking stack in > most OS to extend the architecture concepts that hold for > the OS itself... David and I disagree on the importance of this. It is certainly true that in current commodity OS's, the sticking point for evaluation has been the networking features of the system. I'm unclear on whether these problems mostly have to do with the networking stack per se or with the functionality that is layered above them. For example, I'm not aware of evaluation failures based on bad TCP/IP implementations. I'm aware of quite a number based on cruddy remote file system designs. David: since you have done these evaluations, can you expand on where the problem is? That is: at what layer in the network system do things tend to go wrong? Would you expect systems like QNX, where networking support is implemented in user-mode code, to do better? Anyway, the reason I disagree with David's statement: Networking is the practical bottleneck for current commodity systems, but at higher levels of assurance (EAL5+) it becomes necessary to look at issues of resource denial of service in the operating system. At this point I believe that the process, storage, and memory management subsystems of current systems would struggle because of "free rider" problems in their architectures. Similarly, one runs into a lot of problems with system call design. Based on some of the higher assurance PP work David and I have done I would expect him to agree, and I'll be interested to see if he doesn't. :-) So it's good to talk about the network stack, but let's not make the mistake of thinking that the rest of it is a solved problem. > EROS... will demand the design and implementation of a completely > new network stack. This is good because the stack can be designed > according to the same principles as the OS, but [will] ... > inhibit reuse of existing network stack implementations. I'm not convinced of this. Ignoring security for a moment, I think we could reuse existing TCP/IP implementations without great difficulties, and we probably will do so. The main problems I see in any networking implementation are (a) ensuring that respective connections stay separated and (b) ensuring that one flow cannot impede another. The first is very straightforward to do by going with any of several user-mode TCP solutions. These work by isolating the streams early and processing different streams in different protection domains. The second is a non-problem in practice, because any interference in the network stack is overwhelmed by interference on the wire itself. Interference on the wire is beyond the scope of the operating system. David: this has gotten a bit afield of e-lang. I'ld suggest answering the "what layer is the bottleneck" question here and taking up the rest on eros-arch. shap --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
