In the most recent installments of our series dedicated to SQL Server 2005
Express Edition, we have been exploring one of its more distinguishing and
popular features known as the user instance model. As we pointed out, this
functionality is often employed by .NET applications to provide easily
configurable and transferable data storage. In particular, its advantages
become apparent when combined with ClickOnce technology, used to automate
installations and updates of managed (i.e. .NET-based) code. While we have
already documented relevant ClickOnce publishing parameters and described a
sample scenario demonstrating their practical use, in order to fully understand
all aspects of this deployment methodology, it is important to become familiar
with security mechanisms that affect its outcome. The main purpose of this
article is to present their overview.
Even though the new approach to software distribution frequently eliminates
the need for granting administrative privileges to end-users (which is
typically required when installing non-managed code), their attempts to launch
ClickOnce applications published on remote Web servers or file shares might
still be hindered by predicaments resulting from restrictions imposed by Code
Access Security.
Code Access Security is a protective mechanism built into .NET Framework
(incorporated into its Common Language Runtime). Its primary goal is to control
the range of operations that the managed code is allowed to perform on the
local computer. This is accomplished by associating any sensitive or
potentially intrusive action (such as reading from or writing to a local disk,
interacting with other software, accessing the registry, or printing) with
granular permissions that can be individually granted to any .NET application
that might require them. Note that this is different from the traditional
approach, in which the ability to interact with static objects, such as file
system or registry entries is evaluated by comparing their Access Control List
with the security context in which the code is running (determined by the
account used to trigger its execution). Instead, the Common Language Runtime
determines whether a particular action is permitted by taking into
consideration the following three factors:
- application manifest – an XML-formatted document included with
source installation files, specifying privileges required by the code to
properly execute (forming so-called permission set). It is the responsibility
of a developer to make sure that the resulting set actually matches the intended
use and complies with “the least privilege” principle. While this
approach can potentially expose your system to ill effects of either malicious
or sloppy programming (if requested permissions are excessive), its goal was to
provide full disclosure of such information (with the expectation that software
that operates without elevating its security context would be in higher
demand). - code group – defined on a target computer, consists of an
identifying property of .NET code, such as its origin (source Security Zone or
Web site’s URL) or an inherent characteristic (hash, publisher, strong name,
etc.) and arbitrarily chosen permission set. Characteristics of an application
to be executed (obtained during its initial invocation) are compared against
definitions of local code groups and, once the match is found, its respective
permission set is established (this might be different from a list of
permissions expected by the application as specified in its manifest – more
about this shortly). - .application executable (.NET equivalent of .exe file) – similar
to the application manifest, this XML-formatted file resides in the published
location. In addition to describing deployment options (assigned via the
Publish section of the project’s Properties dialog box) or providing the
application version and relative location of the manifest file, it includes a digital
signature, which uniquely identifies the publisher. If this publisher is
considered trusted by the end user (i.e. its certificate has been added to the
trusted publisher store on the target computer), the Common Language Runtime
(or, more specifically, its subsystem known as trust manager) will
automatically allow the application to run with all the privileges it might
need.
You can define and configure code groups and their respective permission
sets on your system using the .NET Framework 2.0 Configuration console (for
more information regarding using this utility, refer to our earlier
article). Its Runtime Security Policy node allows you to access Enterprise,
Machine, and User level settings. In particular, there are several predefined
Machine code groups, including Internet_Zone, Restricted_Zone, LocalIntranet_Zone,
Restricted_Zone, Trusted_Zone, and My_Computer_Zone entries, with membership
based on the application origin (you can either modify these or define others,
better suiting your preferences – according to such criteria as hash,
publisher, site, strong name, or URL). For the purpose of our discussion, we
will rely on this default setup, since it matches options you will find in the
Security section of a project’s Properties window in Visual Basic 2005 Express
Edition. Selecting the “Enable ClickOnce Security Settings” checkbox
within its interface will allow you to choose between full and partial trust
requirements for the current application. “Full trust” option
indicates that end-users will need to grant your code unrestricted access to
their systems (which is likely to raise security concerns, especially in the
case of Web-based installation). On the other hand, if you want to assign a
partial trust, you must determine the most limited permissions that still meet
the application’s requirements (this process can be automated in the
full-fledged edition of Visual Studio 2005 by using the Permission Calculator
utility). To grant or revoke individual permissions, choose an entry in the
“Zone your application will be installed from” listbox (Internet,
Local Intranet, or Custom) and modify content of the “Permission required
by the application” table.
For example, if you plan to distribute our sample database application via
the Web with the partial trust setting, you need to ensure its ability to
communicate with the locally stored database. Since these actions correspond to
IOPermissions and SQLClientPermissions entries, they would need to be added to
the default permission set associated with Internet or Local Intranet default
zone settings, depending on the location of your deployment Web server
(installation via a network share is by default categorized as originating from
“Local Intranet” zone, while local file system path setup is
automatically fully trusted). Once you publish the application, your final
selection will be recorded in the application manifest.
If an application specifies a permission set that is more extensive than the
one granted based on its code group association in its manifest, a user
attempting to launch it will be prompted to confirm whether its execution
should proceed. This will ensure that privilege elevation takes place only
following explicit acknowledgement. If both permissions sets match (for
example, if the installation is performed from a remote IIS server and the code
can operate within Low Trust limits or a Full Trust code is launched from the
local computer) then no privilege elevation is required and the application
runs uninterrupted (although there are additional caveats to consider, which we
will discuss next). If it turns out that the permission set defined in the
manifest is too limited and does not take into account some actions invoked by
the code, users will be presented with a warning dialog box informing them
about an illegal operation violating local security policy.
It is possible to override the default behavior imposed by a trust level for
an individual application by creating more granular rules based on its
characteristics, such as a digital signature, publisher, hash, or strong name.
For example, when you initiate install of our sample application via the Web or
a remote file share, you will probably receive a Security Warning dialog box informing
you that its publisher can not be verified (since we have not signed it using a
certificate from a trusted source) and asking you to decide whether you want to
proceed. (Note that if you click on the “More information…” link in
the dialog box, you will be presented with other information regarding the
application risk factors, such as the zone it originated from, an indication
whether a permanent or temporary installation will take place, or its need for
increased level of access to local resources). Your confirmation will
automatically update the user-specific list of trusted applications (which you
can verify by reviewing the content of the User’s Trusted Applications subnode
under the Runtime Security Policy node in the .NET Framework 2.0 Configuration
console), so any subsequent launches (even if performed via the Web link) will
continue without any interruptions. You could accomplish the same result by
signing the application manifest using a certificate from a CA trusted by your
clients (which is typically done from the Signing section of the project’s
Properties window in the Visual Basic 2005 Express Edition interface). Another
possibility involves copying source files to the local computer (directly or
via removable media), which, at deployment time, would associate the
application with the My_Computer_Zone code group and its Full Trust permission
set. Keep in mind that a ClickOnce application retains its security zone
association determined by the location from which it originated even after its
installation (i.e. when being launched using a shortcut in All Programs menu).
Finally, note that you can prevent the ability to elevate privileges for a
specific Web site (by adding it to the Restricted Zone) or disable default
privilege elevation behavior (according to which a user is given authority to
approve code execution when presented with the Security Warning dialog box)
altogether, by modifying entries residing under the HKLMSoftwareMicrosoft.NETFrameworkSecurityTrustManagerPromptingLevel
registry key. For specifics regarding this configuration, refer to the “Modifying
TrustManager Configuration” section of the MSDN article Security Considerations
for ClickOnce Deployments. If you are looking for more information on other
topics we discussed here, check the Code
Access Security and Trusted
Application Deployment Overview sections on the MSDN Web site.
This concludes our discussion of ClickOnce deployment characteristics in the
context of SQL Server 2005 Express Edition. In the next installment of our
series, we will turn our attention to its replication capabilities.
