A Roadmap for Administering the Security Context of Managed Code

for RuBoard

Unfortunately, there is no single tool or technology at this time that administrators can use to analyze and modify the complete security state impacting managed code. In fact, some or all of the following security technologies can get involved when managed code gets run:

  • The Code Access Security policy system

  • Windows Security settings

  • The Internet Explorer security configuration settings

  • The ASP.NET security configuration system

  • Database server security

Setting relevant security state in each of these systems is covered in various chapters throughout this book. In this section, you will find quick reviews of each of these systems and where to find more information about them. Some typical runtime scenarios for managed code are then sketched out from which you can glean what security technologies you need to specially focus on for your use scenarios of managed code.

The Code Access Security Policy System

Code Access Security is a core component of the .NET Framework. It is a code-identity “based security system, which means that rights are allotted and security policy is administered based on the identity of managed code. The identity of managed code is typically determined by its place of origin, about which the host of the Common Language Runtime keeps or supplies evidence. Common forms of evidence include the hash, authenticode signature, as well as the URL of origin of a particular assembly. Administrators set CAS policy that maps assembly evidence to permissions that grant access to particular resources. The CAS system enforces that resources requiring a specific level of permissions cannot be accessed by assemblies that do not have the right level of permissions.

The CAS system is driven by a persisted security policy, offering different configuration containments (called policy levels ) for enterprise-wide security configuration and machine-wide and per- user security settings. Security policy can be set using a GUI tool (the .NET Framework Configuration tool), a command line tool for batch scripting security changes, or by programming to the security APIs directly.

NOTE

To read more about how to administer the CAS system using the GUI configuration tool by writing batch scripts or programmatically changing security policy state, please refer to Chapters 18, "Administering Security Policy Using the .NET Framework Configuration Tool," and Chapter 19, "Administering .NET Framework Security Policy Using Scripts and Security APIs."

To find out more about the code-identity “based security paradigm, please read Chapter 4, "User- and Code-Identity “Based Security: Two Complementary Security Paradigms."

To read more about permissions and evidence, refer to Chapter 5, "Evidence: Knowing Where Code Comes From," and Chapter 6, "Permissions: The Workhorse of Code Access Security."


Windows Security

Windows security is largely based on user identity, not code identity, such as the CAS system. Windows protects resources, such as the file system and the registry, using access control permissions defined in security descriptors. Every system object (such as a file) has a security descriptor associated with it. Administrators can set a mapping between user identity or user roles to access control permissions specified in the security descriptors. This entails that the operating system security context is coincidental with user context; in other words, the rights of code to access protected system resources depends on the user on whose behalf the code is executed.

NOTE

The Windows Software Restriction Policies technology is an exception, as will be discussed in the "Windows Software Restriction Policies and .NET Framework Security" section later in this chapter.


As will be explained shortly, the CAS system does not replace or circumvent Windows security settings. Whenever managed code is executed, relevant access control permission settings are still honored.

Internet Explorer Security Settings

Whenever managed code is hosted in Internet Explorer, the IE security settings apply. Managed code gets to be hosted by IE when an HREF to a managed EXE on an HTML page occurs, or when an <object..> element refers to a managed type. In these cases, the Common Language Runtime (CLR) will be invoked by Internet Explorer, and IE security settings determining EXE download and object hosting apply.

To find out more about what IE security settings apply in managed code download or hosting scenarios, please refer to Chapter 21, "Administering Clients for .NET Framework Mobile Code."

TIP

Be sure to regularly check for and install Internet Explorer updates and patches. This will reduce the likelihood that your machines will be susceptible to security exploits that may have been found in the browser. For updates, patches, and further information, please go to http://windowsupdate.microsoft.com.


ASP.NET Security Settings

Whenever managed code is hosted as an ASP.NET application, the ASP.NET configuration system applies. To find out more specifics about setting the ASP.NET security levels for ASP.NET-hosted code, please refer to Part III of this book, "ASP.NET and Web Services Security Fundamentals" (Chapters 13 “ 16) and Chapter 20, "Administering an IIS Machine Using ASP.NET."

Database Server Security Mechanisms

A common application type for managed applications is to operate over databases ”as a middle- tier application or as a front-end application for data access. In fact, the .NET Framework ships with managed OLEDB and SQL data access libraries.

Whenever managed code gets run against a specific database server, such as the Microsoft SQL Server, the security mechanisms of that server will kick in and need to be appropriately configured to allow the access the application you want to run requires. You should refer to the server documentation for administration specifics.

A Different Angle: Security Systems Involved in Common Managed Code Execution Scenarios

You may still wonder what the interplay between the different systems previously discussed is in various scenarios when managed code gets run. This section contains a few key scenarios and the security systems that get involved. Obviously, this list of high-level scenarios is not complete, but it may be of help in determining the security technologies on which you should especially focus.

Managed Desktop Applications

This category contains traditional application types, such as managed word processors or a standalone accounting package. Desktop applications are usually installed from disk or CD-ROM onto the machine and provide productivity functions that stand in isolation from a network of other machines.

In this scenario, typically, only the Windows security settings and the Code Access Security settings come into play. When managed code is loaded, the Code Access Security system determines whether that code has the right to be executing to start with and exactly which resources it can access. That determination is based on the code's identity (its place of origin as expressed in the zone it comes from, its strong name signature, and the URL of origin, among other forms of evidence). If an application attempts to access a resource, such as particular file on disk, that is protected by both the CAS system as well as operating system access control settings, it requires that both systems allow access for the access operation to succeed. For example, if the managed application tries to write foo.bar into the c:\winnt directory, code access security policy needs to have granted access to that directory and file. Also, the user on whose behalf the application is running must have been granted write rights to that location by the Windows security system. If the location c:\winnt is write protected against the user executing the managed application, the fact that code access security policy had granted access to that location will be insufficient for the access to succeed. Both the user-identity “based Windows access control settings as well as the code-identity “based code access security policy are required to grant the appropriate access rights.

If you are primarily running standalone desktop applications, you should therefore familiarize yourself with the Windows ACLs model (see the "Windows Access Control Protections and .NET Framework Security" section later in this chapter), as well as the CAS administration model (see Chapters 18 and 19).

Mobile Code Applications

The Code Access Security (CAS) system allows applications to execute in partially trusted contexts. This means that applications can be run securely without endangering protected resources, such as the file system or registry. By default, all code from the intranet is executed as partially trusted, allowing users to safely execute code whose origin they may not be able to trust. That enables mobile code applications ”applications that are stored on an intranet or Internet site, or even have modules on a separate site, that a user can browse to and execute. The ability to have code run in a secure, semitrusted fashion enables the intranet (or Internet if default policy is changed) as a large application repository, without requiring the user of an application to make explicit trust decisions (such as through pop-up dialogs asking whether an Authenticode Publisher can be trusted).

NOTE

All references to default policy state in this book are references to the CAS default policy shipping in the Service Pack 1 for the .NET Framework.


Mobile code applications will be run through Internet Explorer (IE) as a host to the managed application. IE security settings, such as allowing for <object..> references to managed types to be effective, will come into play. By default, mobile code applications from the intranet will be enabled to run via IE, but you may want to make some fine tuning adjustments. For more information on the IE security setting impacting managed code, see Chapter 21.

In addition to the IE security settings, the CAS policy as well as Windows access control settings will come into play. For example, if the former allows a specific mobile code application to read a file from the hard disk, but the user context has Windows access control settings not allowing such a read operation, then further security settings may need to be changed to fully enable the mobile code application in question. To find out more about Windows access control settings and managed code, see the "Windows Access Control Protections and .NET Framework Security" section later in this chapter; to read more about the CAS policy administration, please see Chapters 18 and 19.

NOTE

Again, by default, managed applications running from the intranet are executing in a constrained security context, preventing access to exploitable resources, such as the file system. There may be a number of mobile code applications that you want to have more trust to access protected resources than what is given them by default CAS policy, such as a mobile code from select publishers that you want to run from the Internet. Please see Chapters 18 and 19 for specific help on increasing the trust for a particular application.


for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net