Default Security Policy and Mobile Code

for RuBoard

Running mobile code on clients is initially bound by the default policy distributed by the .NET Framework. You should evaluate if the provided default policy is appropriate for your organization and then apply any changes that are deemed necessary. The provided security policy is very restrictive by default, so this chapter will cover various ways to properly expand the permissions granted to mobile code.

Default Security Policy's Impact on Mobile Code

In the RTM (the original V1.0 release prior to any Service Packs) release of the .NET Framework, default security policy was set to allow limited permissions for code loaded from the intranet and Internet. In mid-January, Bill Gates announced the strong commitment at Microsoft for the Trustworthy Computing initiative, which is aimed at ensuring that Microsoft as a company will meet customers' needs and expectations around privacy, reliability, and security. As a result of this, the .NET Framework team reconsidered the default security policy for the Internet zone. To truly emphasize the conservative "locked down" default behavior encouraged by the initiative and requested by customers, they decided to release Service Pack 1 (SP1) to remove the ability in default policy for code from the Internet to execute.

NOTE

The remainder of this chapter will assume you have either applied SP1 to your .NET Framework clients or that you installed a version of the .NET Framework that includes SP1.


There are four security zones from where mobile code may originate: Intranet, Internet, Trusted, and Untrusted (also called Restricted):

  • Code from the Internet and Untrusted zones will not be able to execute at all by default. Thus, if a client attempts to load code from such a site, that code will fail to load due to security restrictions.

  • Code from the Trusted zone will be given permissions represented by the built-in Internet permission set and the ability to use the network to connect back to its site of origin. The Internet permission set is a very limited set of permissions that includes the ability to display UI, print documents, use isolated storage, and use a file open dialog.

  • Code from the Intranet zone will be given permissions represented by the built-in LocalIntranet permission set and the ability to use the network to connect back to its site of origin. The LocalIntranet permission set allows everything that the Internet permission set allows plus the ability to use the NT event log, DNS servers, classes from the System.Reflection.Emit namespace, and the USERNAME environment variable.

How to Expand Mobile Code Scenarios

If you want to enable mobile code to run in more scenarios than allowed by default security policy, one thing you can do is add Web sites to the Trusted zone. Figure 21.1 shows the dialog used to add sites to the Trusted zone. You can get to this dialog by running Internet Explorer, opening the Tools menu, choosing the Internet Options menu item, clicking on the Security tab of the resulting dialog, picking the Trusted sites zone, and clicking the Sites button.

Figure 21.1. Dialog used to add Web sites to the Trusted sites zone.

graphics/21fig01.jpg

If a Web site is moved from the Internet zone to the Trusted zone, default security policy will allow mobile code loaded from that site to execute. To understand how to distribute Trusted zone changes to clients on a network, see the Internet Explorer Administration Kit (IEAK).

NOTE

The IEAK kit allows enterprise administrators to customize Internet Explorer settings, enabling administrators to deploy custom browser packages to client machines.

For more information on the IEAK, please see http://www.microsoft.com/ windows /ieak/default.asp.


Another possibility for expanding mobile code scenarios is to change the default security policy. There are generally three different kinds of changes you might want to make. First, you can expand the permissions granted to a given zone. Second, you can explicitly grant permissions to all code from a software publisher. Third, you could explicitly grant permissions to one specific application.

If you choose to change permissions granted to a specific zone, you need to be very careful, because this is the least granular choice. However, this change is probably the easiest to perform because you don't need to add any code groups. Instead, you should just pick the code group for the zone in question and change the permission set. For example, you might want to change the code group for the Internet zone to use the Internet permission set.

TIP

You can use the .NET Framework Configuration tool's Adjust Security Wizard to change the permission level managed code from the Internet receives. To do so, first start up the .NET Framework Configuration tool (Control Panel, Administrative Tools, .NET Framework Configuration shortcut). Then right-click the Runtime Security Policy node and select the Adjust Security Wizard. Select to make changes to "this computer" and select the Internet zone. Finally, push the trust slider to the notch above No Trust. For more information, please see Chapter 18.


The .NET Framework provides the ability to grant specific permissions to assemblies from a specific software publisher. There are two ways to identify a software publisher in the .NET Framework. The first way is to pick an X.509 certificate the publisher uses for signing its applications and use a PublisherMembershipCondition . The second way is to identify the public key from a strong name key pair that the publisher uses for signing its assemblies. A StrongNameMembershipCondition can be used to identify this public key to the .NET Framework security policy. In either case, you can add a code group with the identifying information that grants a specific permission set to the publisher.

The last way to expand trust for mobile code is to identify a specific assembly or set of assemblies that you want to run. For each assembly, you should add a code group that identifies the SHA1 or MD5 hash value and gives the desired permissions. A HashMembershipCondition can perform the identification in .NET Framework security policy.

NOTE

You could also use the site or zone membership conditions to expand trust for specific sites or whole zones. Generally, this is not suggested, because sites and zones are very broad evidence categories and many assemblies unknown to you may satisfy the site or zone membership condition. The membership conditions based on strong name, hash, and publisher certification are the only cryptographically strong means we ship to identify specific sets of managed code in security policy.


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