Technical Report - Microsoft Research

“fred” running any Microsoft program can have access. Furthermore, the pattern languagesupports indirection to common subexpressions (in the naming hierarchy in our implementation).This facility is the equivalent to group expansion in conventional access control systems.We expect to be able to define policy rules from which ACEs can be derived. The hope is toreplace a large number of disparate ACEs with a much smaller set of rules. These rules will workbest in structured environments like file systems. Since access to many resources (e.g., file systemsubtrees) can be adjudicated entirely by the system installer should make this easier.5.5.3 Further Run-time MechanismsChannel contracts can be subtyped so as to specify which messages the holder of an endpointcan send. For example, a subtype of the TcpConnectionContract of Section 4.1 coulddescribe only methods available to a principal that is allowed to listen but not connect. Thus, asubtype corresponds to a set of permissions. For many protocols, channel establishment will berestricted by an access control check that determines whether the requestor should be granted thepermissions implied by the subtype of the channel.Subject to run-time constraints, endpoints can be passed freely between processes. Alongwith them is passed the authority to send messages, as specified in the channel contract. Processesare free to act on such messages without further access checks. However, an access check may beperformed, and in this case it will be based on the identity of the new holder of the channel. Thus,the holder cannot masquerade as the originator.As described above, in the default case for process invocation, the identity of the newprocess is a compound principal of the form invoker + invokee. Other than processinvocation, there are at least two additional scenarios in which a process may choose to lend someaspect of its identity to another process. In one case, a process may want to grant a partner acapability that allows the partner to act under a joint identity with respect to that capability. In asecond case, the system policy may allow a new service to mediate access to an existing service,perhaps adding functionality. In this case, the mediator would need to act on behalf of the originalclient. In both of these cases, we support identity inheritance by specially blessing a channelendpoint: the capability (endpoint) in the first case, and the channel used to bind to the mediatorin the second case. A blessed endpoint allows the recipient to inherit the identity of the partner insome limited context.Processes holding multiple identities can become confused and may use such identities in aninappropriate fashion. Therefore, we hope to limit processes to a single identity in most cases, andto make dealing with multiple identities as easy as possible.6 PerformanceIf Singularity’s goal is more dependable systems, why does this report include performancemeasurements? The answer is simple: these numbers demonstrate that architecture that weproposed not only does not incur a performance penalty, but is often as fast as or faster than moreconventional architecture. In other words, it is a practical basis on which to build a system.On the other hand, this paper does not validate our goal of increased dependence. Measuringthat aspect of a system is significantly more challenging than performance. We do not yet haveresults for Singularity.This section contains measurements comparing the performance of Singularity against othersystems. All systems ran on AMD Athlon 64 3000+ (1.8 GHz) on an NVIDIA nForce4 Ultrachipset, 1GB RAM, a Western Digital WD2500JD 250GB 7200RPM SATA disk (withoutcommand queuing), and the nForce4 Ultra native Gigabit NIC (without hardware TCP offload30