[e-lang] Re: Windows 2000 declared secure

[Jonathan S. Shapiro]

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 majordomo at wasabisystems.com