Jump to navigation

Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.
Otherwise you may find some unperfect stuff here...


Mono Security Manager Part V - InheritanceDemand

Another new feature of Mono 1.1.5 was the support of InheritanceDemand. Inheritance demands very are similar linkdemands but easier to understand (mostly because it has less special cases to consider).

Just like linkdemands, inheritance demands do not happen at runtime. Instead they occurs at load time, i.e. in the processing that follows the loading of an assembly by the CLR. This means that, just like linkdemands, imperative inheritance demand do not exists. Inheritance demands are evaluated in two different places during at load time, depending on where the security attributes were applied [1].

Class and Interface

Inheritance demand are used to limit extensibility, via inheritance (hence the name), of classes. A class that wants to inherit from another class must pass the security checks defined by the base class. The same checks can also be required before a class can implement an interface.

This is much finer grained than using the boolean sealed modifier (which would be applicable to all code). For example the abstract class System.IO.FileSystemInfo in assembly mscorlib.dll can only be inherited by code coming from a fully trusted assembly (i.e. FullTrust).

[FileIOPermission (SecurityAction.InheritanceDemand, Unrestricted = true)] public abstract class FileSystemInfo : MarshalByRefObject, ISerializable {

Method (and the likes)

Something similar also occurs for methods, properties, events... Inheritance demands on a methods controls if a method can override the virtual/abstract method defined in the base class. Methods defined in an interface can also be protected.

Like linkdemands, there are many fun things to do with inheritance demands, e.g. you could allow a class to inherit yours only from noon to midnight on weekdays. But, honestly, inheritance demands are almost always used with code identity permissions (e.g. strongnames, publisher, hash, zone, url...). Which also means that their uses will a little more limited with the CLR 2.0 (more on that another time).

Finally it's kind of hard to catch a SecurityException thrown by an inheritance demand as it is done for all class/methods at load time. So you must catch them when loading an assembly - which most people prefer not to do manually. This also makes them harder to test using NUnit :-(

[1] Actually you can apply inheritance demands (and other SecurityAction) almost anywhere. This is because the restrictions for applying security attributes are the same as for normal attributes - i.e. it is controlled by the Attribute class and not by the SecurityAction. However applying security attributes doesn't mean the CLR will evaluate them. This would make an interesting rule to create (using Cecil of course ;-) in an FxCop style tool.

4/21/2005 19:30:48 | Comments

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.