Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Code Access Security in the .NET Framework : Page 3

Code access security (CAS) is a new feature provided by the .NET Common Language Runtime. CAS is a security model that lets you grant or deny execution permissions to an assembly according to its "properties," called evidence, such as its strong name or publisher. CAS is completely orthogonal to classic security models that lie on the authentication-permissions mechanism based on the identity of the caller. This article is a concise introduction to this compelling and fascinating topic.


advertisement

Code Security Demands
What we’ve covered till at this point is just half of the story. You might have been asking yourself: what if an evil component calls into a trusted component and ask to perform some sensitive tasks on its behalf ? Enter Security Demands.

When placing Imperative or Declarative security demands on your code you enforce only assemblies that have been granted the demanded permissions (according to their evidence) to call into your code.

Security Demands have the CLR parse the whole call stack to check if all the assemblies involved in the call have the required permission.

Making Declarative Security Demands is done using the standard attribute based mechanism and it can be done at assembly, class and method level specifying SecurityAction.Demand.


<FileIOPermission(SecurityAction.Demand, Unrestricted := True)>
Public Shared Function ReadData() As String
 ...
End Function
In the following code snippet the same permission demand is executed imperatively


Public Shared Sub ReadData()
 Dim MyFileIOPermission As New FileIOPermission (PermissionState.Unrestricted)
 MyFileIOPermission.Demand()
End Sub
There are actually other two Security demands type in addition to the one described above: Link demand and Inheritance demand.

The former works as standard demand, but stops the stack walk to the immediate caller of the assembly.

Placing Inheritance demand at class level you request specific permissions to classes that inherit from it. If you place an inheritance demand on the method level, the specified permission will be applied to all overridden methods in a derived class.



Overriding Demands Checks
There might be situations where you might want have your code perform (directly or calling into other assemblies) some actions that require permissions other assemblies in the upper call stack should not necessarily have.

For instance: assembly A is used as an entry point for assembly B downloaded from the internet. Among other things assembly A calls into assembly C that writes some info into a log file.
If assembly B makes a FileIO security request, this security request would fail since, walking up the call stack, the CLR would find that assembly A is not allowed to perform such action.

To have CAS stop walking the stack on a specific permission check request, the assert method come to rescue: assembly A will call


<FileIOPermission(SecurityAction.Assert, All := "C:\Log.txt")> _
Public Sub MakeLog()
or, imperatively:


Dim MyFileIOPermission As New FileIOPermission (PermissionState.Unrestricted)
MyFileIOPermission.Assert()
Of course, Assert is ignored when called against a permission not granted to the assembly trying to asserting it.

Calling RevertAssert or RevertAll removes an active Assert.

Calling SecurityAction.Deny on the permission class object has the opposite effect of calling Assert: it blocks a stack walk on the method that called deny, even if the assembly had enough rights to have the security check succeed.

Finally, calling SecurityAction.PermitOnly is similar to Deny: in both cause stack walks to fail when they would otherwise succeed.

The difference is that Deny specifies permissions that will cause the stack walk to fail, but PermitOnly specifies the only permissions that do not cause the stack walk to fail.

In the following picture the net effect on the permissions available after a call to Assert, Deny or Permitonly is shown graphically.


 

Conclusions
Literature on code access security is still rather scarce at present. Certainly this feature lets us tighten the security of our applications, covering security domains where identity based security is inadequate or inappropriate.
I bet all of you have thought of a couple of situations where CAS could have been helpful in your previous projects, the .NET programmer community will learn in the future the best effective way to take full advantage of this new feature.





Enrico Sabbadin is a software developer (MCP) that works, since 1995, on distributed and Internet based applications design on the Microsoft platform. He is an author for several Italian programming magazines and for the ASPToday web site, and occasionally speaks at Microsoft MSDN conferences in Italy. Enrico maintains at his own site a MTS FAQ (http://www.sabbasoft.com).
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date