[UseCase:] Microsoft.NET Stack Walk

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: [UseCase:] Microsoft.NET Stack Walk

Hi,

Here's a use case derived from a document that Microsoft circulated to the last OASIS SS-TC face-to-face meeting.  It has to do with software execution in a .NET environment.

Carlisle.

8<----------------------------------------------------

        XACML v1.0 Use Case

        Title:  [useCaseTitle]

Microsoft.NET Stack Walk

        Terse Description:  [One line description of Use Case]

Evaluation of permissions and resulting execution of code in a Microsoft.NET environment.

        Version: [v#.#]

1.0

        Submitted By:  [orignalSubmitter]

Carlisle Adams (but entirely derived from the circulated Microsoft document)

        Date:  [lastModifiedDate]

September 7, 2001

        Summary [Simple description of the Use Case]

The permissions associated with each point in the entire calling sequence are evaluated before the actual requester is granted or denied access.

        Scope:  [The boundaries for which the Use Case represents a Process]
Actors:  [For lack of a better term, the NOUNs by which the verbs act
upon]
Assumptions:  [What preconditions and/or in-process assumptions were
made in developing the Use Case?]
Non-technical Factors: [List any non-technical issues that may have an
effect on the process: legal, regulatory, industry standards, etc.]

        Process Sequence
----------------
Primary Process Flow:  [Detailed description of the entities and actions
comprising the Process Flow]

At run time, permissions are evaluated based on the execution of code.  An assembly, "A3," provides its evidence, along with evidence from the host, to the policy evaluator. The evaluator also takes the permission requests from the assembly into consideration in creating a grant of permissions, "G3." Assembly A3 is called by assembly A2, which has been called by assembly A1.  When assembly A3 performs an operation that triggers a security check, the permission grants of A2 and A1 are also examined to ensure that they have the permissions requested by A3. In this process, which is called stack walking, the permission grants of every assembly on the stack are inspected to see whether the grant set contains the permission demanded by the security check.  If each assembly on the stack has been granted the permission demanded by the security check, the call succeeds. If any assembly has not been granted the demanded permission, the stack walk will fail, and a security exception will be thrown.

The code-access security stack walk protects code against the "luring" attack. In this common attack, malicious code tricks more trusted code into doing something it can't do alone-effectively leveraging the good code's permissions for ill intent. This kind of attack is extremely difficult for developers to guard against, but the stack walk ensures that if lower-trust code is involved, the permissions available are reduced to that of the lowest-trusted code.

The result is that code may be acquired from sources with varying degrees of trust, and run with restrictions appropriate to the particular context of that code's execution.

        Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

The interesting thing about this use case is that it highlights a requirement similar to delegation, but not identical.  The permissions of every piece of code in the calling sequence are checked, but these permissions may (and likely will) be assigned independently (perhaps by different authorities, particularly for code downloaded from the Web).  When one routine calls another, it is not delegating any privileges to that called routine; the called routine must have its own set of privileges.

In some ways, this requirement is similar to the concept of co-signing for documents.  As with delegation, the privileges of several entities are checked (not just the immediate requester, but others as well in a kind of chain), but no delegation of privilege has occurred from one of these entities to another.

        Alpha Process Variant:  [Detailed description of the entities and
actions comprising a Process Flow variant that introduces a new or
different interpretation of Primary Process Flow]
Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

        Beta Process Variant:  [Detailed description of the entities and actions
comprising a Process Flow variant that introduces a new or different
interpretation of  the Process Flow]
Flow Diagram: (optional?)
Key Points:  [Issues that the Author wishes to explicitly identify as
goals to be met, issues to be resolved or other information that
warrants particular attention]

        [...]

        Glossary: [Definition of terms used]

        References: [List of references used - URLs are a good way to make
friends!]
 
(document from Microsoft to SAML f2f meeting:  August 2001)