Susan Bradley has been kind enough to make some room for me over at MSMVPS.com, so this blog is finally moving to a spot where it won't be necessary to sign in to leave comments.

The new blog is at http://msmvps.com/blogs/calinoiu/. The RSS and Atom feeds are at http://msmvps.com/blogs/calinoiu/rss.aspx and http://msmvps.com/blogs/calinoiu/atom.aspx, respectively.

I'm closing the comments on this blog, but I've copied all existing posts to the new blog, so please feel free to comment on the old posts over there if you happen to feel the urge...

There's a new version of the Bordecal.ImportsSorter add-in available for download. This new version allows shortcut keys to be permanently assigned to the configuration and/or sorting menu items via VStudio options. The hashes for the new MSI file are:

MD5: f89f3c1bfa2a40adbb67315de8fef148

SHA1: c54803ba3392ca68ca29fd4dc9b4b359606f46c7

The problem

Back when ASP.NET was first introduced, I had pretty high hopes that the new controls would offer support for automatic HTML encoding. Unfortunately, there was very little of this, and most of it was more than a bit lukewarm (more on this later). In some ways, things have improved a bit in v. 2.0, but they're considerably worse in others.

Before you read any further, you might want to ask yourself which ASP.NET controls perform HTML encoding for you and under what circumstances this is done. If the answer doesn't leap to mind, you've perhaps got a first inkling that there might be a little problem with API consistency and/or the documentation. Then again, maybe you've never worried about HTML encoding in your web applications, in which case I'd strongly recommend that you read up on HTML injection and cross-site scripting. A good starting point might be CERT Advisory CA-2000-02.

We'll look at which controls perform HTML encoding soon. First, we're going to need to nail down some conceptual stuff because not all encoding is created equal. You may already be aware that HTML, URLs, and client-side script use different encodings. For the sake of simplicity, the remainder of this post will refer mainly to HTML encoding, although the other two forms of encoding do merit consideration as well.

There is more than one flavour of HTML encoding, even within ASP.NET. The first is exposed via the System.Web.HttpUtility.HtmlEncode methods. These encode the characters >, <, &, ", as well as any characters with codes between 160 and 255, inclusive. The other main encoding flavour used by ASP.NET is "attribute" encoding, which is exposed via the System.Web.HttpUtility.HtmlAttributeEncode methods. In ASP.NET 1.1., these encode the & and " characters only. In ASP.NET 2.0, these encode the characters <, &, and ".

Attribute encoding ought to be a superset of full HTML encoding that also encodes the single quote character in case that's what happens to be wrapping the attribute. However, as you may have noticed from the above, the ASP.NET version of attribute encoding is even wimpier than its full encoding brother. To make matters worse, the full HTML encoding implemented by ASP.NET is no great shakes in the first place. Security isn't the only reason for HTML encoding, and failure to encode everything outside the low ASCII range can impact on page readability when client browsers don't apply the correct code page (which happens more often than you might think, whether it's the client's or the server's fault).

Now that we know what kinds of HTML encoding are available in ASP.NET, let's take a look at the encoding support offered by the built-in ASP.NET controls.  The following table covers some of the more commonly used controls and properties.  (There are, of course, many other controls and properties that one might wish to see encoded, but I've tried to keep the list down to things that most folks are likely to use reasonably frequently.)

Assuming you've actually taken the time to read the above, you might have noticed that there are five basic patterns of encoding usage:

1. No encoding ever applied.
2. HTML and/or attribute encoding, as appropriate (with a bit of additional URL and/or javascript encoding applied when appropriate), applied all the time.
3. Attribute encoding applied for attributes, but no encoding applied for other text.
4. Optional encoding set via a boolean property, defaulting to applying the encoding.
5. Optional encoding set via an enumerated property, defaulting to not applying the encoding.

If this strikes you as perhaps a wee bit inconsistent, you wouldn't be alone. Wouldn't it be great to see a consistent approach that telegraphs well and acts as a pit of success? If all the controls performed HTML encoding by default but allowed overriding when necessary (preferably via a single approach), the vast majority of developers writing for ASP.NET would end up generating a more secure, more reliable applications with considerably less effort.

Workarounds

While we're all waiting around for the ASP.NET team to eventually provide reasonable built-in support for HTML encoding, what can we do to ensure that our apps are both protected from HTML injection and character mis-rendering? A good starting point would be to fully encode all data (i.e.: anything not 100% known at compile time, and even some stuff that is) that will be pushed to the client browser. Unfortunately, as was already mentioned above, the built-in encoding scheme leaves a little something to be desired. Luckily, the ACE team folks at Microsoft have been working on a couple of tools that take a more robust approach to HTML (and URL and script) encoding. Rather than blacklisting a fixed set of potentially problematic characters for encoding, they whitelist a set of known safe characters (low ASCII a-z, A-Z, 0-9, space, period, comma, dash, and underscore for HTML encoding) and encode everything else. This quite nicely takes care of both security and appearance issues, and you may wish to seriously consider using this approach rather than calling System.Web.HttpUtility.HtmlEncode to perform your HTML encoding.

Regardless of which HTML encoding approach you select, you're quickly going to run into a bit of trouble with double encoding if you simply start assigning pre-encoded text to control properties (e.g.: someTextBox.Text = HttpUtility.HtmlEncode(someString)). When dealing with malicious input, this is pretty much a non-issue. However, not all data that ought to be encoded is malicious, and you usually wouldn't want users seeing stuff like a &gt; b rather than a > b. Unfortunately, if we want to avoid double encoding in the set of controls that perform non-overrideable encoding (including attribute encoding), we need to use custom controls. To make matters worse, it can require rather a lot of work to subclass most of the controls in order to override the encoding behaviour. In quite a few cases, simply starting from scratch would probably make more sense than trying to subclass the built-in controls. Also, even for those controls where double encoding wouldn't be an issue (e.g.: Label, CheckBox), it's probably worth considering using custom controls anyway since the pain of authoring the custom control isn't likely to outweigh the cumulative effort of all the manual encoding calls you might make across all your projects.

Don't like these workarounds? Maybe it's time to start complaining...

ASP.NET introduced a fancy new user input validation framework that, at least at first glance, appears to be a great advance over the complete lack of built-in validation support in ASP.OLD. Declarative validation is certainly wonderful stuff, and getting client-side validation with no additional effort (at least if your clients are using supported browsers) isn’t too shabby either. Overall, using the built-in validation controls certainly seems like a good idea, particularly for those folks who wouldn’t be performing any validation otherwise because of the amount of work involved.

But what about those of us who had been performing validation all along? Do the ASP.NET validation controls really offer equivalent protection to our former "manual" validation? Unfortunately, for many of us, the answer is probably "no". The main problem lies with the validation paradigm chosen for ASP.NET, which has the following properties:

1. Each validation control operates independently of the others.
2. The validation process does not output a validated value.

So what’s wrong with that, you ask? Well, each of the validation controls needs to re-read the target control value, as does the code that will ultimately process that value. To make the problem a bit more concrete, let’s look at the example of validating a birth date provided via a text box:

In the above example, each validation control reads the text box value independently, which means that they cannot build upon parsing and restriction steps performed by the other validators. In addition, when our code needs to process the birth date, it must go back to the text box and read the string value again. That mean that there are at least 5 reads and 4 separate parsing operations from the original text box value, each of which represents an opportunity to parse inconsistently with respect to culture and/or format. In addition, there’s no guarantee that each of those 5 reads is even accessing the same value since it’s possible for the text box’s Text property to be altered between the reads (even if this is somewhat unlikely in an ASP.NET app).

How can we address this problem? There are plenty of workarounds, including using only custom validation controls, but that means quite a bit more work for developers. A much more reliable approach would involve reading the "raw" value from the text box only once. It would then be passed from one validator to another in a pre-defined order and would only require a single parsing. In the birth date example, the validator at step 2 would output a strongly typed DateTime value (assuming, of course, that step 2 validation passed), and that’s the value that would be passed to the validator at step 3. The output from step 5 would be the value that our code would read, rather than going back to the text box to read its Text property.

It’s entirely feasible to develop such a framework, but it’s also quite a bit of a lot of work, particularly when one considers addition of appropriate design-time support. It’s obviously not the sort of thing on which most shops would want their developers spending time. Unfortunately, it’s also not the sort of thing that many shops would be willing to pay for as a third-party product, particularly given that most developers probably perceive themselves as getting by just fine with the existing ASP.NET validation controls.

On the other hand, it would probably be a reasonably small project on the Microsoft scale of things, and I suspect that I’m not the only one who would sleep better if the built-in tools would help the Morts of this world develop more reliable and secure applications out of the box, particularly given that most of us use applications built on those tools sooner on a more or less regular basis.

For quite some time now, I’ve been harbouring an increasing bit of frustration with ASP.NET. Overall, I like the platform, and I think that it’s a great advance over ASP.OLD. Unfortunately, there are a few areas in which I can’t help but feel that the design team missed the boat by just a wee bit too much, and compensating for these lacunae can mean a ridiculous amount of work for the individual developer.

There are three main areas that have been grating on my nerves of late:

1. User input validation
2. HTML encoding
3. Culture usage

I’d love to see the ASP.NET team address fundamentals like these in upcoming versions, but new features generally garner considerably more interest amongst users than fixing things that very few people ever realized were broken. In an attempt to perhaps rouse a bit of interest in the latter, I’m starting a short series of posts on the above topics, starting with What’s wrong with ASP.NET? Validation.

There's a new version of the Bordecal.ImportsSorter add-in available for download. The only change is a fix for a bug that raised its ugly head when the shortcut menu was polled by another add-in. The hashes for the new MSI file are:

MD5: b91a7abde826173a0d7c9f5e05126b35

SHA1: 1b54e49189a921a07eecca82749860b6f9e41d7a

I've seen quite a few articles over the past few months that make the assumption that one can only connect to the hosting database from SQLCLR code running at the SAFE permission level. I can't seem to find any official MSDN documentation that would directly reinforce this misconception, so I'm guessing that it stems from the limitation of the SqlClientPermission at the SAFE level to only allow use of the following connection strings (with optional specification of the Type System Version parameter):

context connection=true

context connection=yes

Unfortunately, the documentation for the SqlClientPermission.Add method is a wee bit ambiguous with respect to the effect of preventing arbitrary target database specifications in the connection string, and one might easily be led into believing that preventing use of the database parameter will prevent connections to unintended databases. However, while it will prevent mucking about with the connection string, that's not enough to prevent connecting to other databases.

For starters, the SqlConnection object has a ChangeDatabase method that allows one to target another database after an initial connection has already been established.e.g.:¹

using (SqlConnection connection = new SqlConnection(@"Data Source=(local);Initial Catalog=AllowedDB;Integrated Security=True"))
{
 connection.Open();
 connection.ChangeDatabase("ForbiddenDB");

 using (SqlCommand command = connection.CreateCommand())
 {
  command.CommandType = CommandType.Text;
  command.CommandText = "SELECT DB_NAME()";
  Console.WriteLine((string)command.ExecuteScalar());
 }
}

Now, one might argue that this is actually a bug, and that ChangeDatabase method ought to demand SqlClientPermission for the target database before making the switch. However, it's quite possible to bypass the SqlClient layer entirely and make the switch inside database code, so any additional protection at the SqlClient level would only provide a false sense of security and probably isn't worth implementing.

The next approach invokes making a direct database context switch from T-SQL using the USE statement. e.g.:

using (SqlConnection connection = new SqlConnection(@"Data Source=(local);Initial Catalog=AllowedDB;Integrated Security=True"))
{
 connection.Open();

 using (SqlCommand command = connection.CreateCommand())
 {
  command.CommandType = CommandType.Text;

  command.CommandText = "USE ForbiddenDB";
  command.ExecuteNonQuery();

  command.CommandText = "SELECT DB_NAME()";
  Console.WriteLine((string)command.ExecuteScalar());
 }
}

Effectively, this means that SqlClientPermission provides no protection against using any particular database within a given SQL Server instance. You might guess that the SQLCLR might add some additional protection against database switching from within hosted code, but you'd be wrong. The above techniques work just as well against the SQLCLR context connection as they do against a plain, old vanilla connection as shown above. SAFE or not, SQLCLR assemblies can connect to any database in their host SQL Server instance assuming, of course, that user permissions also allow the connection.

Odd exceptions at odd times

If you apply a PrincipalPermission attribute to a class in order to restrict the users and/or roles that are permitted to use the class, you may start seeing security exceptions like the following being thrown at unexpected times (like, say, when your application is quitting):

System.Security.SecurityException was unhandled
Message="Request for principal permission failed."
Source="mscorlib"
StackTrace:
        at System.Security.Permissions.PrincipalPermission.ThrowSecurityException()
        at System.Security.Permissions.PrincipalPermission.Demand()
        at System.Security.PermissionSet.DemandNonCAS()
        at YourNamespace.YourClass.Finalize()

What's up with that?

The basic gist of the above exception that the demand for your specified PrincipalPermission is failing when the finalizer for your class is invoked. If your class also happens to be disposable, and disposition suppresses its finalization, you might be tempted to believe that this problem occurs because the thread principal couldn't satisfy the original PrincipalPermission demand at construction. However, things are a wee bit more complicated than that...

Finalization is triggered by the garbage collector and runs on a separate thread controlled by the garbage collector. This means that the principal that you set on your application's thread won't be applied to the thread on which an instance of your finalizable type gets finalized. Your PrincipalPermission demand will always fail at finalization, regardless of the thread principal set within your application.

Another surprise might be that there's an object available for finalization at all if the PrincipalPermission demand fails when the constructor is invoked. What you actually end up with in such a case is a partially constructed instance of your type. This instance won't be available to the invoking code, so it won't be subject to disposition, but the garbage collector will still attempt to finalize it despite the fact that it isn't fully constructed.

So what can I do about all this?

The simple answer is you need to make it possible for the finalizer (and any other methods it calls) to run despite the fact that the finalizer thread cannot satisfy the class-level PrincipalPermission demand. You can do this by applying a PrincipalPermission attribute that allows unauthenticated callers to the finalizer (and any methods it calls). The C# form of this attribute would be:

[PrincipalPermission(SecurityAction.Demand, Authenticated = false)]

The VB form would be:

<PrincipalPermission(SecurityAction.Demand, Authenticated:=False)>

Obviously, if you're going to be removing the requirement for the class-level PrincipalPermission from the finalizer or any other methods, you should also ensure that these methods don't perform any actions that should require whatever user identity or role membership specified by the original PrincipalPermission.

You may want to also consider applying the same PrincipalPermission reversal on any methods used for disposition, even if these are not invoked from your finalizer. (This would be a bit of an odd design choice in most cases, but if that's what you're using, you should be addressing the consequences.) The main reason for this is that disposition might not be invoked under the same principal as was in place at construction. As with finalization, you should ensure that your disposition methods don't perform any "high-privilege" actions if you do choose to reverse the PrincipalPermission requirement.

If that was the simple answer...

The good news is that the above approach is pretty much the only approach. It's reasonably clear-cut, and there's not much that you can do in terms of variation on the theme. The bad news is that, if you're running into this particular problem, chances are pretty good that you should perhaps be concerned about some of the finer details of finalization and disposition. If you're interested in learning more about these, I'd recommend reading Chris Brumme's blog entry on finalization. If you're implementing disposition as well as a finalizer, you should probably take a look at the recommended disposition pattern, and maybe even the whitepaper on .NET Framework Resource Management.

Surprise!

User instances are a new capability of SQL Server 2005 (Express edition only) that are supposedly intended to allow non-admins to attach database files without requiring additional permissions. This actually works just fine and, at first glance, it probably strikes most folks as a lovely least-privilege accomodation. The unfortunate bit that might not be immediately obvious to the casual user is that this is accomplished by granting the connecting user sysadmin privilege over his user instance. This means that every connection to a user instance is a connection running as sysadmin.

So... What's so bad about connecting as sysadmin?

If you're at all familiar with secure practices around database connectivity, you've probably heard that you should never connect under a sysadmin login unless you're connecting for the express purpose of performing administrative tasks. The main reason for this is that a sysadmin login has unlimited control over the SQL Server instance, as well as being able to "climb" out of the SQL Server instance via extended stored procedures (or hosted SQLCLR code, in the case of SQL Server 2005) to affect other machine resources. In other words, code running under a sysadmin login can fully control the SQL Server instance and can do anything on the machine or network that either the login account or the SQL Server service account can do. It's also possible to impersonate other Windows accounts when calling outside SQL Server, so the damage potential isn't necessarily limited by the privileges of the login and service account.

Yikes! But, ummm... Yikes!

Hmmm... Sounds like running user instances might be just a wee bit on the risky side, doesn't it? After a bit of a stumped initial reaction, the little voices in my head started evaluating the implementation against SD³+C ("secure by design, secure by default, secure in deployment, and communications") criteria, which is supposed to be an integral part of the Microsoft security development lifecycle. I can't help but feel that some less risky choices might have been made along the way, but perhaps that's just my paranoid nutbag side talking. You decide...

Secure by design?

The main goal of user instance mode seems to be allowing applications to attach database files even when running under a limited privilege user account. That's pretty necessary if you're going to, say, push user instance mode SQL Server Express as a replacement for Jet. That said, might some safer design choices have been made when choosing how to implement this requirement? This would allow even dbcreator membership to be revoked when it isn't actually needed, which could be the case if one were to configure the user instance template data files to pre-connect to a designated set of databases.

1. Does the connecting user really need to be a sysadmin?
   Probably not. Membership in the dbcreator role would probably have been quite sufficient for the purposes of attaching database files without invoking additional risks around control of the instance configuration and allowing code to call out of the database. However, a potentially more interesting design might allow a true sysadmin of the master SQL Express instance to designate the role membership of a user instance creator.
   
   
2. Is the connecting user account really the best choice for the service account?
   On the surface, choosing to run the user instance under the connecting user's account might actually seem to be a good choice. After all, it ensures that code run within the user instance can't do anything that the user himself can't do (unless, of course, impersonation is used). However, if you turn things around a bit and assume that an attached database might come from a less than ideal source (say, passed around from one user to another, all of whom act as dbo and sysadmin while the database is in their hands), running with the full privileges of the connecting user all of a sudden doesn't sound so good...
   
   Could another choice have been made here? Granted, there are some challenges around designating the permissions granted to any alternate account. However, one obvious possibility would be to allow a master instance administrator to designate per-user service accounts for user instance mode. As with master instance service accounts, such a mechanism could automatically assign the minimal user permission set required for service operation, thereby reducing the administrative burden. A configurable design could also allow for enabling/disabling user instance mode by user (with disabled as the default state for a properly "secure by default" design).
   
   
3. Do user instances really need the full functionality of stand-alone instances?
   If the true purpose of user instances is to permit applications to attach local database files, why include any functionality beyond what's needed to act as a pure database server? Do such applications really need to be able to run extended stored procedures like xp_cmdshell? If not, why include it at all?
   
   
4. What CAS permissions ought to be assigned to assemblies hosted in an attached database?
   Unfortunately, all assemblies hosted by the SQLCLR are assigned local zone evidence, which means that a database loaded from a remote location (either with an application loaded from that location or as an attached remote database) will be granted unrestricted CAS permissions under default CAS policy. In order to prevent remotely sourced applications from escalating their own CAS privilege via this mechanism, the SQLCLR probably ought to assign zone evidence based on database source locations in a manner similar to what the stand-alone CLR does for assemblies.

Secure by default?

Well, it looks like someone did at least give this one the old college try. For example, regardless of the master instance setting, a user instance will have xp_cmdshell use disabled by default. Unfortunately, it's trivial to enable the option from within any application connected to a user instance since the user is running as a sysadmin, so this is essentially just a bit of cosmetic cover-up.

Given the current design, the only real "secure by default" setting that I can see would be to deploy SQL Server Express with user instance mode disabled by default. Since most machines on which the Express edition will be installed will likely never need to run user instances, it's really rather disappointing that it's enabled by default in the first place. Then again, this is an obvious ease of use vs. security trade-off, and it's not exactly difficult to imagine the meeting at which the decision was made...

Secure in deployment?

There's little an administrator or user can do to make user instances more secure if they're enabled. There appears to be no information at all out there about the risks of their use, forget about guidance on "how to use it securely". We'll have to wait to see if updates will be easy to deploy, but updating all user instances on any given machine will certainly pose some potentially interesting challenges.

Communications?

Well, I guess we'll see... ;)

Ouch! Band-aids, anyone?

If you need to install the SQL Server Express edition and want to protect yourself against these risks, there are a few things you can do. For starters, unless you absolutely need user instances, disabling them would probably be a really good idea. This can be done by executing sp_configure against the master SQL Express instance on a machine as follows:

sp_configure 'user instances enabled', '0'
GO

RECONFIGURE
GO

Developers who distribute SQL Server Express edition with their applications might also want to keep this in mind. If you don't use user instances in your application, you should probably disable them as part of the installation. Also, given the risks involved with running user instances, you might want to consider avoiding their use if at all possible. (BTW, if you've installed Visual Studio 2005 on your machine, there's a good chance that SQL Express edition was also installed, and you might want to take a little break from reading this in order to run off and disable user instances.)

So, that's all fine and dandy if you don't need user instances at all. What happens if you really need to run an application that uses user instances? For starters, you might want to limit which users can create user instances. Unfortunately, as far as I know, the only way to do this at present would be to remove user permissions on the directory created for a user instance. In other words, for any user to whom you wish to deny user instances, you would need to create a %USERPROFILE%\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data\SQLEXPRESS folder, then remove the user's NTFS permissions on the folder. Since this is a major pain in the caboose, as well as easy to miss doing for any given account, it's the sort of thing you might want to consider automating via a default login script or similar mechanism. BTW, if you do make this permission alteration, other processes such as backups may be affected, so you might want to do some pretty thorough testing before, say, pushing this sort of thing out to your entire domain...

What about CAS permissions?

Sorry, but CAS isn't going to help much here if you allow connections to a user instance. Code with any SqlClientPermission can do anything the connecting user is allowed to do via the SQL Server instance. When connecting to a remote instance (or even a local non-user instance), the user's capabilities are usually (or so one would hope!) constrained by their NTFS permissions, SQL Server permissions, and limitations imposed by the configuration of the SQL Server instance. However, running as sysadmin on a user instance, these contraints are mostly absent. If you grant any SqlClientPermission to managed code that permits connection to a user instance, you are effectively granting permission for that code to do anything the user can do. The end result for a malicious application is the same as if you had granted unrestricted CAS permissions (aka "full trust"). In other words, you shouldn't be granting SqlClientPermission that includes the possibility to connect to a user instance to any assembly unless you would happily grant unrestricted permissions as well.

This means that granting unrestricted SqlClientPermission to any code (other than as part of a full trust grant) is a pretty horrible idea. Unfortunately, if you want to grant "almost unrestricted" SqlClientPermission that excludes the right to connect to user instances, the CAS permission configuration UIs won't be of much help. Instead, you'll need to define the permission "manually". The XML definition for such a permission might look like this (watch out for fakey angle brackets if you copy and paste):

‹IPermission 
 class="System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1"
 AllowBlankPassword="True"›

 ‹add KeyRestrictions="User Instance=;" KeyRestrictionBehavior="PreventUsage" /›
‹/IPermission›

If you want to grant additional permissions to a network-sourced assembly so that it can connect to a SQL Server instance running any server on your network, I'd recommend you use something like the above permission rather than an unrestricted SqlClientPermission grant. Otherwise, you might unwittingly be granting that assembly essentially unrestricted permissions over the machine on which it's executing via code run within a user instance.

Wrapping things up...

In my opinion, SQL Express user instances just plain don't meet the SD³+C bar, and disabling them is probably the best way for most of us to protect ourselves against the risks they introduce. Then again, I am a something of a paranoid nutbag, so your mileage may vary greatly... ;)

Once I actually started using my imports sorter add-in from the Larkware 2005 Developer Tool Programming Contest on a semi-regular basis, there were a few things that started irritating the heck out of me (and were presumably worse for everyone else). Finally found a bit of time to fix and test things, and a new version is available for download here, with updated documentation here. The new stuff includes:

1. Option to not display the imports/using block after sorting.
2. Option for duration to display the imports/using block after sorting, if display is enabled.
3. Removal of whitespace from between imports/using directive lines. (This avoids an irritating problem with extra trailing lines that occurred when re-sorting the imports/using block with inter-group lines inserted.)

If you use the add-in and find a problem, just give me a shout at calinoiu@gmail.com...

I'd been hoping that the details of the SQL CLR CAS permission sets might make it into the SQL Server Books Online or other relevant documentation by the RTM timeframe. Unfortunately, I can't seem to find anything that even begins to resemble a listing of the permissions, never mind coverage of some of the pickier details of their assessment and consequences. I'd already started trying to investigate some of this on my own during the beta and, after spending a bit more time with the RTM build (i.e.: pretty much wasting a perfectly good Saturday), here's what I think I've discovered so far... (Click here to read the whole kit and kaboodle.)

The ISO what?

For quite some time now, I had been assuming that that the ISO/IEC list of software quality attributes is pretty much common knowledge, at least amongst the architect/analyst crowd. It turns out I was wrong. After a first hint in this direction a few weeks ago, I started asking around to see if folks had ever heard of the list. Despite some deficiencies in my sampling methodology (which pretty much entailed asking folks about it whenever I happened to think of it), the 100% blank stare response rate pretty much settled that question. At least it gave me something other than the fully trusted GAC to blog about... ;)

Momma and Poppa Bear

For those of you who might care about such things, this quality attribute stuff comes out of the software and system engineering sub-committee (SC 7) of the joint ISO/IEC tecnical committee on information technology (JTC 1). The relevant published standard is ISO/IEC 9126, which currently ships in 4 parts, all of which are listed under (surprise!) the standards published by JTC 1/SC 7. If you want to buy copies of these beasties, you might want to check the list of international member stores rather than buying directly from the ISO mother-ship and letting your credit card company profit off a conversion from Swiss francs.

What if I don't have buckets of money to spend on this stuff?

OK, time for a small confession. I've never forked over money for the full standards either. My bad, although I do keep hoping to eventually work on a project that would merit it. In the meantime, I'm still using the quality attribute list even though I'm blissfully ignorant of the full methodology outlined in the standards, and there's no reason you can't do the same. The simple fact is that many/most of us don't work on applications that are likely to merit the full methodology anyway, and development of such applications usually tends to be supported by QA teams that get paid to worry about this stuff on a full-time basis. ;)

If you want to get a copy of the quality attributes list without shelling out the big bucks, a good place to start is Wikipedia. Unfortunately, the Wikipedia list doesn't include descriptions of the subcharacteristics, but you can pick those up from the EAGLES-I report. One thing to watch out for is that these lists are not all-inclusive. For example, since both are based on the 1991 release of ISO 9126, they are missing some subcharacteristics that appear to have been added in the ISO/IEC 9126-1:2001 release. At least a partial list of these can be seen at http://www.hostserver150.com/usabilit/tools/r_international.htm#9126-1. Also, you should keep in mind that the list was never meant to be exhaustive, and you may find that you need to make your own additions. For example, I like to add an "accessibility" subcharacteristic under "usability" since, even though it's sort of implied under "operability", I want to make sure that it gets considered in its own right when using the list.

So what the heck is this thing good for anyway?

So, now that you've got the list, what are you going to do with it? Obviously, it's not suitable as a guideline for everything that ought to be done in any given piece of software. If you tried to fully implement the whole kit and kaboodle in any single application, you would probably still be working on the beast when the heat death of the universe eventually rolls around.

Personally, I like use the list more or less as a checklist of things to discuss with the client during the requirements gathering phase of a project. Ideally, I like to run through at least two rounds of such discussion, preferably in meetings attended by all the key decision makers on both the business and technical sides. The first round takes place at the beginning of the requirements gathering process and, while it can help identify non-functional requirements with major project impacts, it is intended mainly to familiarize the business-side folks with the quality attibutes so that they can consider them as they develop their functionality wish lists. The final (or as final as can be) decisions around the quality attributes would be made at the second round of discussions, which would take place towards the end of the requirements gathering process, once at least the broad strokes of the functional requirements are presumably known.

Finally wrapping up my rebuttal of Shawn's listing of reasons for forcing full trust of assemblies in the GAC...

6.a) "Based upon the assumption that GACed assemblies are receiving FullTrust, tools such as NGEN can have simpler code paths around security."

Not too many users of the platform are likely to lose sleep worrying about how complex Microsoft's private implementation of such tools might be. If any given feature is too difficult to implement without eroding the security protections offered by the platform, dropping the feature might be a better solution than dropping the protection. Of course, this only holds true if one values security over the feature in question.

6.b) "And reducing complexity in code paths that involve security helps to reduce the risk of bugs, which is a very good thing."

Is it really necessary to sacrifice our ability to protect ourselves against similar bugs in the GACed assemblies distributed by both Microsoft and others simply in order to reduce the risk of bugs appearing in a much smaller set of supporting tools? Is Microsoft not concerned that the many GACed assemblies it distributes (and not just as part of the Framework itself) might be potentially just as buggy as these tools?

On the more general side of things...

It seems to me that this point is the actual reason Microsoft wants to force full trust in the GAC. The other points strike me as being little more than justifications that Microsoft is attempting to use to convince their clients (and maybe themselves?) that we shouldn't object to the change. Since I don't find the other five arguments to be even slightly compelling, I'd like to examine this "tools gains" issue in a bit more depth...

Last week, an article by Reid Wilkes covering new NGen features became available on the MSDN Magazine site. I had already suspected that the change in CAS behaviour might be the result of a security vs performance trade-off, and this article rang quite a few bells for me despite the fact that it made no mention of security (or at least not any that I could find).

Assuming my guess is right, and the forced full trust of GACed assemblies is meant to support improved performance via reduction/elimination of runtime permission verifications in extended NGen scenarios, a couple of reasonable questions might be:

1. Why move in this direction at all?

The performance vs security trade-off is nothing new. Presumably quite a few decisions were made during the design of the v. 1 .NET Framework regarding where and how to strike the balance between these two quality factors. What could have changed to make things swing the other way? Has Microsoft has been receiving vociferous and frequent complaints about .NET performance? Has it been too difficult to sell folks on the idea that improved security comes at a cost? Is this due to nothing more than altered composition of the relevant product teams, with different people making different choices?

2. Is there no alternative that might satisfy both those who want enhanced performance and those who want to maintain full CAS functionality?

I can think of at least a couple of potential options:

a) CAS can already be disabled entirely, thereby allowing runtime stack walks for permission verification to be avoided. This is a client-controllable option that can be used to improve runtime performance. Why not tie assumed GAC full trust to this option, or some similar switch to be introduced for this purpose only? (Or might this sort of thing be the "complexity in code paths that involve security" that Microsoft is attempting to avoid?)

b) Accept that at least some performance and security goals may be incompatible. Instead of trying to accomodate all potential users with one platform that is too slow for some and too insecure for others, focus on the more generally important goal (security, of course ;)) in the generally distributed Framework and release an alternate framework for the other crowd.

Of course, (a) may be more complex, and (b) might be more expensive, but implementing security is rarely both easy and cheap.

Continuing with my rebuttal of Shawn's listing of reasons for forcing full trust of assemblies in the GAC...

4. "If an application is hosting the CLR, it has the ability to protect itself from assemblies it doesn't trust to load. For instance, SQL Server 2005 does not allow the Windows Forms library to load. Applications can provide an AppDomainManager and HostSecurityManager in order to disallow some assemblies from loading, or to tweak their grant sets."

That's nice. Unfortunately, it does nothing to protect users against the majority of .NET applications, which are run outside of such custom hosts. I suppose this does mean that one could force stand-alone .NET apps to run in a host of one's choosing, but I have a really hard time seeing this is a general workaround for reduced CAS policy flexibility. Amongst other things, who could be trusted by most users to build, test, and distribute such a host (keeping in mind that a buggy host might introduce security problems of its own)?

5. "Assembly-level declarative security still works to reduce the grant set, so if you really need it, there is a knob you can turn to reduce the granted permissions of an assembly stored in the GAC."

This works for the assemblies we create, but not the ones we consume (either via our own code or applications authored by others). It would be naive not to recognize that some developers will be GACing assemblies just to acquire a guaranteed full trust grant. These are not folks who would be likely to be willing to reduce their permission grants in any way. They may also do some pretty silly things like blindly asserting any permission their own callers might need, thereby creating some rather ugly security holes on our machines.

If the platform allows developers to abuse the system with such ease, it should at least allow users to protect themselves with as little effort.

Continuing with my rebuttal of Shawn's listing of reasons for forcing full trust of assemblies in the GAC...

3.a) "Since you have to be an administrator in order to add an assembly to the GAC, it is already considered special from a security standpoint."

Ouch. Got a few things to say about this one...

i. Joe User can't write to the Program Files directory either. Does this make it special too? (Rhetorical question, I hope. ;))

ii. One absolutely does not need to be an administrator to add assemblies to the GAC. Even under default ACLs (at least on fully patched Windows XP and .NET Framework 1.1), power users can also do so. Although I haven't tried this, I'm guessing that manipulation of ACLs might also allow any user to do so.

iii. Unfortunately, far too many enterprise users (particularly in smaller businesses) and almost all home users run as admins. In practice, there's nothing special about a location to which all these folks can write. These are also the users who can most benefit from the protections offered by limitation of CAS permissions.

iv. Windows 98, Windows 98 Second Edition, Windows ME are all listed as supported versions for the beta version of the v. 2.0 Framework. Assuming this doesn't change, the supposed "difficulty" of placing assemblies in the GAC shouldn't be a factor in the decision to force full trust of GACed assemblies.

3.b) "For instance, strong name verification is skipped for assemblies that are loaded from the GAC."

Well, I've never liked that one--surprise! :) Amongst other things, consider those poor Win9x users and all those folks who run with sufficient privileges to alter the contents of the GAC. Also, given that the ACLs on the GAC can be altered, it seems ridiculous for the platform provider to be making decisions based on an assumption that the default ACLs will be in effect.

Continuing with my rebuttal of Shawn's listing of reasons for forcing full trust of assemblies in the GAC...

2.a) "By side-effect, assemblies in the GAC did already receive FullTrust."

Under default policy only. I'd be one of the first to argue that this default policy is probably too permissive, but it's a little late in the game for that. At least those of us who don't like the default policy can alter it so that not all locally installed code is fully trusted. Forcing full trust of all assemblies in the GAC would deny us that possibility.

2.b) "The only way that you could change this would be to either not grant MyComputer FullTrust, or create an exclusive code group that matched the strong name of the assembly and granted less trust."

Yup. I run almost all my machines (both desktops and servers) with only SecurityPermission\Execution granted to the My_Computer_Zone code group. It causes the occasional bit of pain, but I prefer it to the alternative.

After introducing a Microsoft plan to force full trust all assemblies in the GAC, Shawn Farkas posted follow-up inviting further feeback. Included in his post are six points explaining some of the reasoning behind the change. In my opinion, none of these reasons even begins to justify the change, and I'd like to present some counter-arguments to each. I'll address each of Shawn's points in a separate post here, with the individual points and subpoints labeled for ease of discussion.

Starting with point 1...

1.a) "Assemblies in the GAC build up the managed platform that all managed applications can run on."

Not all assemblies in the GAC are meant to form part of the general .NET platform, just as not all DLLs in the Windows\System32 folder form part of the Windows platform. Microsoft lost the right to assume this the moment every Tom, Dick, and Harry were allowed to put their assemblies in the GAC.

1.b) "In order to build up a platform where any application, trusted or not, can run safely, it makes sense that you need to trust the assemblies making up that platform."

But that trust need not be blind. See my earlier post on trust decisions for why one might not want to grant full trust to even the most trustworthy assemblies.

1.c) "If you don't trust an assembly enough for any code to be able to call into it, then the best place for it is probably not the GAC"

i. On inappropriate GACing:

By and large, the decision to place any given assembly in the GAC or not is made by the folks who author and distribute applications, not the folks who run their installation packages. I might decide not to install an app once I find out that it puts assemblies in the GAC in a manner that I find unnecessary (and I'll be far more likely to make this decision if the change goes through), but I won't be adjusting someone else's app or installer to avoid putting their assemblies in the GAC.

ii. On trusting GACed assemblies:

Under v. 1.x rules, one could set policy to grant only partial trust to assemblies in the GAC, so allowing other folks' apps to put assemblies in the GAC did not necessarily cause a trust problem. The problem is introduced by eliminating the possibility to the restrict GACed assemblies to the permission one feels they actually merit.

This post is in response to a Microsoft plan to force full trust all assemblies in the GAC regardless of CAS policy settings.

CAS

Imagine for a moment that you could find an "intro to CAS" document from Microsoft that gives a simple, clear statement of the purpose of CAS. What would that statement be?

Unfortunately, my own search for such a document failed to turn up anything that didn't jump directly from the "why" into the "how" of CAS, leaving the reader to infer the purpose from the "why". In the absence of a clear statement of from Microsoft (unless someone else has seen one?), I'm going to propose the following:

The purpose of code access security is to permit restriction of the activities available to managed code beyond the limitations imposed by permissions (not) granted to the user executing the code.

If one agrees with the above statement, then it should be very difficult to accept a modification to CAS that makes it impossible to control permissions for any managed code. After all, if the purpose of CAS is to allow restriction of code permissions, how does eliminating the restrictability of permissions for some code fit in?

The GAC

What's the purpose of the GAC? I had a little better luck this time around and found the following statement in the Global Assembly Cache topic in the .NET Framework Developer's Guide:

"The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer."

One could argue that the above isn't necessarily a definitive statement of purpose, so let's also consider the following instructions from the same document:

"You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required."

CAS isn't mentioned at all. There's nothing about placing assemblies in the GAC in order to obtain a full trust grant. Unfortunately, if the plan to force full trust for GACed assemblies goes through, folks will violate the above instructions simply to ensure their code is granted full trust. The worst abusers of the GAC will probably be those developers who are least familiar with (and/or least willing to abide by) the principles and practices of secure development. Do you really want their assemblies being guaranteed full trust on your machine?

UPDATE: Microsoft is already recommending that folks place assemblies in the GAC solely in order to obtain a full trust grant.

CAS and the GAC

I actually happen to think that the introduction of GacMembershipCondition (assuming it sticks around) and the associated easing of assignment of special permissions to GACed assemblies is quite reasonable. If .NET 2.0 were to ship with a code group granting full trust to assemblies in the GAC (redundant though that may be if all local code is already granted full trust), I wouldn't complain despite the apparent violation of the "secure by default" principle. After all, those of us who care about running code with least privilege would still be free to modify CAS policy in order to reduce the permission grants, and ignorant and/or lazy developers wouldn't be able to grab full trust simply by GACing their assemblies on our machines.

However, enforcing full trust for GACed assemblies has some potential consequences beyond simply removing our immediate ability to limit the permissions of potentially "bad" code in the GAC. I would imagine that quite a few very smart people spent rather a lot of time mapping out the goals for CAS and the GAC. If one accepts that their visions for CAS and the GAC were reasonable, then corruption of those goals should not be irrevocably built into the framework. Of course, no software feature is ever strictly final, but Microsoft has repeatedly demonstrated an unwillingness to make breaking changes. Unfortunately, if this change goes through, the rather large segment of the developer population that will want to run their code as fully trusted will likely complain very loudly if the change is ever reversed.

What do you think will happen a few years down the road if folks at Microsoft decide that the original vision was right after all?

This post is in response to a Microsoft plan to force full trust all assemblies in the GAC regardless of CAS policy settings.

For some time now, I've been rather disappointed with the view of code trustworthiness that seems to be generally espoused at Microsoft. IMO, there are at least two main issues to address when evaluating the trustworthiness of code (and/or its source):

1. Do I trust it to not be deliberately malicious?
2. Do I trust it to not contain any exploitable flaws?

As far as I can tell, Microsoft seems to be concentrating mostly on #1* (and not just with respect to CAS and the .NET Framework). However, I worry at least as much, if not more, about #2. Unfortunately, even the most well intentioned of developers are not necessarily all that competent, particularly when it comes to security.

Even when developers are competent and careful, there's every reason to expect that their code will contain at least some exploitable flaws since bugs related to security will likely be at least as frequent as problems in any other area. Therefore, even if I trust the developers of a given assembly to be both non-malicious and competent, I would still want to run their code with least possible privilege. This is simple defense in depth.

If all assemblies in the GAC are to become fully trusted regardless of policy settings, administrators will have no way of enforcing least privilege for these assemblies. Is the loss of this ability really worth any trade-off with respect to possible gains that might result in other areas?

*Interestingly enough, the Code Access Security topic in the .NET Framework Developer's Guide does mention #2 as one of the reasons for the limitation of code permissions under CAS. Unfortunately, it would seem that someone has forgotten about this along the way.