Silverlight Security III: Inheritance
Over the last few days we've looked at the basics of the CoreCLR security model in Silverlight, and how to tell which platform APIs are available for applications to call. Let's wrap up this mini-series on CoreCLR security by looking at how the CoreCLR transparency model interacts with inheritance in the Silverlight platform.
From what we already know, we can define a logical ordering among the transparency levels:
- Transparent (application / platform)
- Safe critical (platform only)
- Critical (platform only)
What's all this got to do with inheritance? This ordering becomes very important when determining if a class is allowed to derive from a parent class. A class may only derive from a type at its level in that ladder or higher. It may never derive from a base class lower on the ladder. This means, for instance, that critical types can derive from any other type while a transparent type may only derive from other transparent types.
We can apply this to types in a Silverlight application relatively easily. Since all application code is transparent, it stands to reason that all of the types in application assemblies are also transparent. Applying this rule, we see that application types may only derive from other application types or transparent platform types. (*)
In the same way that the security rules for method access are on top of the standard runtime access rules, the rules for inheritance are also in addition to the standard runtime inheritance rules. So an application type may not derive from a sealed transparent type in a platform assembly for instance, since the CLR does not allow derivation from sealed types.
One of the more interesting things to do once you've derived from a type is to start overriding virtual methods (or implementing interface methods). Not surprisingly, we have security checks for these overrides as well which are also based upon the transparency model. When talking about overriding methods, it's convenient to group the different security groups into two accessibility levels:
- Transparent and safe critical code
- Critical code
When grouped this way, we see that transparent code has access to everything in the first level while only critical (including safe critical) code has access to the second level.
With that in mind, the simple rule is that a method may only be overridden by another method in the same accessibility level. So a Silverlight application may override any virtual from within their application, as well as any transparent or safe critical platform virtuals. (Assuming, of course, that the application type was allowed to derive from the platform type).
The same rule applies when it comes to interface implementations. A Silverlight application may implement all methods on any interface defined by the application itself. If the interface is supplied by a platform assembly, then the application my only implement methods which are either transparent or safe critical. Practically speaking this means that Silverlight applications may not implement any interface which contains any critical members.
We can summarize the CoreCLR security inheritance rules for applications into three quick rules:
- Types may only derive from base types that are transparent.
- Only transparent or safe critical methods may be overridden
- Only transparent or safe critical interface methods may be implemented
(*) This true in 99.9% case. There is another rule about the visibility of the default constructor of a class (which we'll get into next week when we dig deeper into the security model), which also requires that the base class' default constructor (if it has one), must be transparent as well. Practically speaking, you're not generally going to find interesting transparent types in the platform which do not also have transparent default constructors, so this rule doesn't normally come into play.