> Suppose I am building an application server that implements a
> protected subsystem (Saltzer terminology?)
Gregory:
You are switching problems. The problem you are now pursuing is certainly interesting, but it isn't the challenge problem.
The challenge problem calls for the service to live within a protection domain, and it is therefore a "protected subsystem" in the sense of Saltzer and Schroeder.
However, the fact that it lives within a protection domain is *all* that is meant by the term "protected subsystem." There is no implication that the client trusts the service. If you trusted the service, there would be no reason to restrict the rights that you granted it, and the entire structure of the challenge problem would become rather silly. A trusted service of this form, by the way, might be labeled a "trusted subsystem."
The problem that I originally challenged you with was a precursor to building recursively *confined* subsystems. In the confinement scenario, you may or may not trust the subsystem to produce correct answers, but you do not trust it to be a good citizen about your vital information.
> In other words, I perceive that an application server is a mini-
> operating system with respect to enforcing security within
> its protected subdomain and hence must rely on its own code
> to "do the right thing." No?
Hopefully the above description has made it clear that you are now talking about a different problem.
The point of the challenge problem was precisely that you cannot make this assumption in practice. In practice, you hand your authority to code whose provenance is unknown. Making an assumption such as the one you propose is therefore unhealthy. How many of the 15,000 programmers at Microsoft who contributed to your code environment are you sure you can trust?
There are certainly applications where the server must be trusted. In such a circumstance, the model you are pursuing is basically sound.
The question, though, was how to lay the groundwork for controllably including incompletely trusted components (such as ActiveX controls) into your application without having your application be compromised as a result.
The end goal is first to reduce the number of components that must be trusted by fiat and second to focus attention on those components that still need to be taken on faith. Taken together, these might winnow the trust problem down to something manageable.
shap