Permission Set XML for a Custom Trust Level
By Don Kiely
I ve written a lot in this Secure ASP.NET column about partial trust ASP.NET applications. Simply put, if you deploy a Web application using the default Full Trust, you deserve whatever abuses hackers rain down on your site. You ve bypassed one of the most powerful techniques Microsoft has made available to protect your site and users. Shame on you!
Here s a brief recap of partial trust ASP.NET applications. By writing and deploying an app with partial trust, you are limiting what the code can do to a small subset of all the permissions available within the .NET Framework. This restricts the app even beyond what Windows will allow it to do. This means that when a hacker gets control of your site (and don t think they won t), s/he will be severely restricted in what damage s/he can cause. Simply put, partial trust apps implement the security principal of least privilege, in which the code gets the permissions it needs to do its job, and absolutely no more. Sure, it s a bit more work but aren t your app, your server, your network, and your users worth it? Not to mention your job?
But just like running as a non-admin on your desktop machine (you do, don t you?), writing partial trust Web apps requires some thought, tricks, and insight into how ASP.NET works. One thing you ll need to do when customizing a policy file is to generate the XML for each permission in a permission set.
When you customize a policy file to define a custom trust level, you need to define a permission set that contains the permissions granted for that policy level. Besides the named permission sets FullTrust and Nothing, there is an ASP.NET permission set that contains the complete set of permissions granted under that trust level. For example, here is a portion of the ASP.NET named permission set for the standard medium trust level in ASP.NET:
You can find the complete permission set definition in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web_mediumtrust.config file that is installed with .NET.
There is no GUI in Visual Studio, or any other tool that I m aware of, that will create this XML for you. You can certainly, with a bit of work, come up with the correct XML using trial and error by looking at the properties of each permission object in the .NET Framework. But the XML is just the serialization of each of the permission objects. This makes it almost trivial to create the necessary XML.
The code below is a console application that creates a new NamedPermissionSet object, then creates new permissions and adds them to the permission set. Then it uses the ToXml method of the NamedPermissionSet object to get the necessary XML:
static void Main(string args)
NamedPermissionSet permSet = new NamedPermissionSet("ASP.Net", PermissionState.None);
AspNetHostingPermission aspPerm =
EnvironmentPermission envPerm =
WebPermission webPerm =
new WebPermission(NetworkAccess.Connect, "$OriginHost$");
The resulting XML is a little fancier than what you need, with the full strong name of each permission class. And I cheated a bit. Because I used the policy file variable $OriginHost$, the serialization added leading and trailing slashes as escape characters. But otherwise, the XML is what you need for a policy file, even though the formatting is not very human readable:
<PermissionSet class="System.Security.NamedPermissionSet" version="1" Name="ASP.Net">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME"/>
<IPermission class="System.Web.AspNetHostingPermission, System, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Level="Medium"/>
<IPermission class="System.Net.WebPermission, System, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1">
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.