This post was migrated from an older system. Some links may point to content that no longer exists. Comments were not migrated.
Code access security (cas) is an interesting technology.
Obviously, it’s an integral part of the .Net framework and therefore has been around for a long time. However, chances are most folks didn't know about it or even really cared. You almost had to go out of your way to see CAS in action. Case in point, Asp.net v1.0 applications were forced to operate with Full trust. As for executables, the only time you are typically required to deal with CAS is whenever you attempt to run a managed executable from a network drive. CAS kicks in and prevents you from running the exe; thus, the "workaround" is to run the exe from a local drive.
Windows SharePoint Services, a premier web application, comes along and brings code access security to the forefront. In a heartbeat, a lot of questions popped up:
- What is Code Acess Security?
- How and why does SharePoint interact with code access security?
- I'm an admin for a SharePoint server, why do I care?
- As a WebPart developer, should I care?
Obviously, there are a lot of papers on MSDN and various sites across the internet that describes the fundamentals of code access security (
msn search link). As I said earlier, CAS has always been around but it was probably just a footnote in the minds of many people.
The last three points are definitely more interesting. They all tie in together. You shouldn't look at cas from the perspective of only a developer or a server administrator.
Why does SharePoint play with code access security?
- The first part of the answer is because Asp.net v1.1 is able to work with partially trusted assemblies. This is a change from Asp.net v1.0. Thus, to be a good Asp.net v1.1 citizen, SharePoint needed to work with partially trusted assemblies.
- The second part of the answer is to provide the most secure default operating platform possible for custom code. The newest incarnation of Web Parts required assemblies to be installed on the server. Ensuring those assemblies can be locked down via code access security management was a key requirement.
How does SharePoint interact with code access security?
There is one definitive document on this very subject - Microsoft Windows SharePoint Services and Code Access Security (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_sp2003_ta/html/sharepoint_wsscodeaccesssecurity.asp). The primary author is a cool dude... ;-)
As an administrator, why do I care? Isn't my deployment made more difficult by code access security?
- The number one benefit is the ability to control how much access a web part assembly has to your resources (i.e. registry, file system, sql servers, etc) regardless of user identity.
- Deployment may become more complex; however, I would counter that it's well worth your time and effort to fully understand how this security mechanism operates. Tools such as wppackager help make deployment of web part assemblies and custom code access security permissions much more palatable. As the SharePoint community grows, I fully anticipate more robust tools will come online.
- The flip side is that you take a shortcut and say one of two things:
- "just install it in the GAC, it will have Full trust and everything will work", or
- "just raise the trust level to Full"
I hear these "recommendations" all too often and, truth be told, this doesn't make me happy. It's both a sloppy and insecure practice, especially if you do it because you don't want to learn about code access security. Blindly granting Full trust, is no different than leaving your keys in the ignition after you've parked your car. Full trust means the code can do ANYTHING it wants.
Windows SharePoint Services recommends custom web part assemblies should be installed in the BIN. There is only one server configuration where the recommendation changes - servers using IIS host header definitions (see my previous post).
As a Web Part developer, should I care? Why not just tell whoever is installing my assembly to push it into the GAC or otherwise grant my assembly Full trust?
Answer to first question - ABSOLUTELY.
Answer to the second question - as a server admin considering your Web Part, you just lost my business.
Excuse me? I lost your business? Don't you like my WebPart?
As developer, take the time to understand what permissions are required to run your code. Write them down, convert them to a custom permission set and include them in the setup and marketing materials.
Having a complete list of permissions ...
-
makes it easier for administrators to understand what your code does and how it will, or will not, affect their servers, and
-
potentially protects you when something goes bad and angry server admins are storming through the night with pitch forks and torches looking for someone to yell at.
On top of knowing what permissions you need, be smart... write code that knows how to deal with scenarios where the expected permissions haven't been granted. Although you may provide an admin a list of cas permissions, it's really up to the admin to grant them.
If a WebPart developer doesn't know what permissions are required, how can a server administrator trust that the WebPart won't ...
- do something not intended with a server resource (whether or not malicious), or
- blow up if the trust level is tightened down
Give the admin the option to operate your WebPart with Full trust, don't blindly require it. Giving the admin this option will make the admin much receptive to concept of introducing your WebPart to the system.
Is it a real world scenario to require a list of code access security permissions?
Yes. I know of several large server systems where WebPart assemblies are throughly analyzed before they are even put on test servers (much less production servers). Those requirements include a full listing of code access security permissions... saying "install it in the GAC" just won't do.
Let's look at the Syndication Generator WebPart. The
help document lists the following permissions:
-
AspNetHostingPermission.Minimal
-
SecurityPermission.Execution
-
SharePointPermission.ObjectModel
This is a contract between me, the developer, and you, the server admin. It effectively says that the Syndication Generator WebPart only needs these 3 permissions to operate. That's it. Nothing else... it doesn't need access to the file system, databases, sockets, dns, registry, etc., etc.
What happens if an admin has problems with his server and detects that an unknown web part has been deleting files from his system? The contract effectvely says it couldn't have been the Syndication Generator. The list of permissions makes it easy to eliminate my code as being at fault (especially if the part is operating with only those permissions).
Fun stuff. Don't avoid code access security. It's extremely helpful.
-Maurice