Beruflich Dokumente
Kultur Dokumente
Contents Overview Lesson: Deploying .NET Applications with Security Settings Lesson: Deploying .NET Applications with Publisher Identity and Code Integrity Review Lab 12: Deploying Applications with Security Course Evaluation 1 2 9 29 31 34
Information in this document, including Uniform Resource Locators (URLs) and other Internet Web-site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express, written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. !"2004 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Microsoft Press, Active Directory, ActiveX, Authenticode, JScript, MSDN, Outlook, PowerPoint, Visual Basic, Visual C#, Visual Studio, Win32, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States or other countries, or both. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Overview
Introduction
This module explains the deploying of secure applications. The module explains the various deployment techniques used to deploy .NET applications. It also discusses various techniques, such as Microsoft Authenticode signing and strong-name signing, to authenticate .NET assemblies and verify the publisher identity. After completing this module, you will be able to:
! !
Objectives
Deploy .NET applications with security settings. Deploy .NET applications with publisher identity and code integrity.
Note The procedures provided in this module, except those contained in any practice, demonstration or lab exercise, are generic and have not been customized to support the images built for this course.
Introduction
In this lesson, you will learn about the deployment techniques of .NET applications. To run an application on any computer, you must first deploy the application. The deployment technique you choose determines the level of code-access security for the application. After deploying the application, you must ensure that the application runs without throwing security exceptions, for which you need to deploy the application with the updated security policies. This lesson describes the code-access security based on the deployment technique used to deploy an application. The lesson also describes how to deploy an application with modified security policies. After completing this lesson, you will be able to:
! ! !
Objectives
Explain deployment techniques of .NET applications. Explain the use of code-access security with .NET deployment techniques. Deploy .NET applications with updated code-access security.
Introduction
To run an application on any computer, you must first deploy the application. To deploy a .NET application, use any of the following deployment techniques:
! ! ! !
XCopy and no-touch are the new deployment techniques introduced in VB.NET. Microsoft Windows applications traditionally use MSI and cabinetfile deployment techniques. XCopy deployment The XCopy deployment technique copies the directory that contains the application to the location from which you must run the application. This technique applies if your application consists only of .NET components, because .NET components do not require further registration when you relocate components. When you use the XCopy deployment technique, you must ensure that you retain the file attributes and ACLs for the files and folders that you copy from the development location to the target location. Example of XCopy deployment You can use the XCopy deployment technique for deploying Web services and ASP.NET Web applications in which you can copy application files from the development computer to the Web server computer where you need to run the application.
No-touch deployment
The no-touch deployment technique copies the Windows Form application of the VB.NET application that you need to deploy from a Web page. The Web page may be on the Internet or on an intranet. This technique copies the application and its components from the Web page to a special folder, named Internet download cache, on your computer, from where you can run the application. Implementing the no-touch deployment technique requires that you have a continuous Internet connection when you run the application.
You can use the no-touch deployment technique when the application is based on Windows Forms and deployed on the Internet. The application can be designed for the automatic download of dependent components to run the application from the Internet. This deployment technique creates a Windows Installer (.MSI) package. This package is a setup that includes a user interface to specify installation options and a directory location where you can copy and install application files. Note To create and edit Windows Installer packages, you can use Orca.exe, which is a database table editor. Orca.exe provides a graphical interface to validate and highlight entries where validation errors occur in a Windows Installer package.
The Windows Installer deployment technique is useful when the application contains Microsoft ActiveX or .NET components that require special registration. You can also use the Windows Installer package to deploy an application if the application needs to provide:
! !
Additional configuration settings, such as NTFS security settings. The option to reboot the system as part of the installation procedure or disable a Windows operating system service to install any component of the application. Installation options for the user. Desktop shortcuts or Start menu items. The installation of .NET DLL components on the global assembly cache (GAC). The location of the application directory to be determined by the user.
! ! !
Cabinet-file deployment
The cabinet-file deployment technique uses cabinet (.cab) files to distribute ActiveX components on the Internet. If the .cab file contains a .NET component, the deployment technique functions similar to the no-touch deployment technique.
You use the cabinet-file deployment technique if you want to use an ActiveX component on a Web page.
Introduction
There are various techniques you can use to deploy .NET applications. The deployment technique you choose determines the level of code-access security for the application. When you deploy a .NET application, the .NET code-access security provides a restrictive environment to run the application. This environment is known as the .NET code-access security sandbox. When you deploy your application on the Internet or intranet, the clients accessing your application identify that the application is from a secure zone and run it in the sandbox environment. If you install and run your application in the My Computer zone, where all permissions are granted to the application, the application is considered to be running outside the .NET code-access security sandbox.
When you deploy a .NET application using the XCopy deployment technique, the application cannot run in the .NET code-access security sandbox environment. This is because when you use the XCopy deployment technique, you copy the entire application to the local computer. Therefore, the application runs from the My Computer zone of the local computer. When you deploy an application using the Windows Installer package, the client cannot run the application in the sandbox environment. This is because the application is installed on the client computer where the application runs in the My Computer zone. Therefore, the application inherits the security settings of the My Computer zone and ignores the original location of the application, which is the Internet. When you deploy an application using the no-touch or cabinet-file deployment techniques, the application is granted permissions based on the zone from which the application runs. For example, if you run the application from a remote location on an intranet, the application has permissions assigned only to the intranet zone. In this situation, the application is said to be inside a sandbox because it can perform only the actions for which it is assigned permissions.
Introduction
To run an application on a client computer without throwing security exceptions, you need to deploy the application with the updated security policies at the location where you want to run the application. You can use methods to deploy an application and update the security policies at the target location. For example, you can create a security policy deployment package to register the security policy updates at the target location. To deploy the security setting updates using a security policy deployment package, create a custom development application and package the security updates in an .MSI deployment file. To create a custom .MSI security policy deployment package, perform the following steps: 1. Click Start, point to Administrative Tools, and click Microsoft .NET Framework 1.1 Configuration. 2. Right-click the Runtime Security Policy node. 3. To start Deployment Package Wizard, select the Create Deployment Package option. 4. In the Choose the Policy Level to Deploy dialog box, select the level of security policy for which you want to create a deployment package. 5. Specify the name and location for the new Windows Installer file, and then click Next. 6. Click Finish to create the deployment package. The .MSI deployment package helps you update the security policies required for running the application.
In this practice, you will create an MSI that will deploy the enterprise security policy setting of your computer on to the client computer. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.
Lesson: Deploying .NET Applications with Publisher Identity and Code Integrity
Introduction
This lesson describes the various techniques, such as Authenticode signing and strong-name signing, to authenticate applications and to set up packages. The Authenticode-signing technique attaches an X.509 certificate to an assembly to verify the publisher identity, whereas strong-name signing enables you to ensure application integrity. This lesson explains the procedure for creating X.509 certificates and then attaching these certificates to .NET assemblies using Authenticode signing. You use Authenticode signing to ensure the authenticity of applications downloaded from the Internet and verify the identity of publishers. Strong-name signing ensures integrity of assemblies by providing a unique name to .NET assemblies. In this lesson, you will learn how to apply strong-name signing to assemblies. After completing this lesson, you will be able to:
!
Objectives
Create an X.509 certificate for .NET applications by using the MakeCert.exe utility. Explain Authenticode signing. Apply Authenticode signing to setup packages. Apply Authenticode signing to .NET assemblies by using the SignCode.exe utility. Explain strong-name signing. Sign in .NET assemblies using a strong name.
! ! !
! !
10
Introduction
In the process of cryptography, the sender of a message must provide public key access to the recipients. On a large network, it is difficult to guarantee that the public key belongs to a trusted repository. To solve the problem of public key identification and distribution, you use various certificates. For example, in Microsoft Windows, you use X.509 certificates to authenticate a user, an application, or a computer. An X.509 certificate contains the name of the organization and contact information and is similar to a company logo. This certificate has a Software Publisher Certificate (.spc) format. An example of this certificate is MyCourseCert.spc. You can either create an X.509 certificate or obtain it from a certificate authority (CA). Normally, you obtain this certificate for your organization by signing up for a digital ID from CAs. CAs require a large fee and take a long time to perform an extensive background check. Therefore, for the purpose of this exercise, you will create an X.509 test certificate. However, it is important to note that you should not deploy an application signed with a test certificate because the test certificates, which do not contain the issuer name, are not issued by a trusted authority. You use the MakeCert utility to create an X.509 test certificate. Using the MakeCert utility, you create a public and private key pair and associate the key pair with a specified publisher name. Then you use this utility to create an X.509 certificate that binds a user-defined name to the public part of the key pair. Finally, you package the X.509 certificate in a .spc file.
11
The following table describes common options that you use with the MakeCert command.
Option -n x509name Description Specifies the name of the certificate, which must conform to the X.500 standard. The name is expressed in double quotes, preceded by CN=; for example, CN=MyCertificate. Description Specifies the location of the container that contains the private key. If a key container does not exist, this option creates it. Specifies the location of the certificate, which can be either the current user or the local computer. Specifies the store name of the output certificate. Specifies a serial number from 1 to 231-1. The Makecert.exe command generates a default number, which you can change per requirements. Specifies the signing authority of the certificate, which must be set to either commercial or individual. Displays the command syntax and the basic options for the MakeCert utility. Displays the command syntax and the extended options for the MakeCert utility. Specifies the private key file name. If the file does not exist, this option creates a private key file using the specified name.
-$ authority -? -! -sv
To create an X.509 certificate, complete the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, click Visual Studio .NET Tools, and then click VS.NET Command Prompt. 2. In the Visual Studio .NET command prompt, change the current directory to the directory where the application to be signed resides.
12
3. Run the MakeCert.exe utility to create an X.509 certificate named MyCertificate by using the following command:
MakeCert -n "CN=MyCertificate"sv MyPvtKey.pvk MyCourse.cer
The above command also creates a private key named MyPvtKey.pvk and opens a dialog box where you can specify the password for the private key.
4. In the Create Private Key Password dialog box, enter a password in the Password and Confirm Password fields. This password is associated with the MyPvtKey.pvk private key. 5. In the Enter Private Key Password dialog box, re-enter the password, and then click OK. The sv option extracts the private key, and you need to re-enter the password to gain access to this key.
6. Use the cert2spc MyCourse.cer MyCourseCert.Spc command to run the Cert2Spc.exe utility. The Cert2Spc.exe utility packages the X.509 certificate created in the previous step in a .spc file. The .spc file is the required format that you use to authenticate .NET applications.
13
In this practice, you will create the X.509 certificate using the MakeCert.exe utility. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.
5. In the Create Private Key Password dialog box, enter the appropriate password in the Password and Confirm Password text boxes, and then click OK. 6. In the Enter Private Key Password dialog box, re-enter the same password, and then click OK.
14
7. To package the X.509 certificate in a Software Publisher Certificate (.spc) file, run the Cert2Spc.exe utility, as shown:
cert2spc MyID.Cer MyCertificate.Spc
8. Using Windows Explorer, browse to the following location to view the Private Key and the Certificate files that are created: install_folder\Practices\Mod12\Practice02\Starter\MyCertStore
15
Introduction
When downloading code or software from the Internet, you may face the threat of downloading malicious code. It is difficult for you to identify a harmful piece of software or code before downloading it from the Internet because you do not know the publisher of the software. Internet Explorer 3.0 and later versions use the Authenticode technology, which enables you to identify the publisher of signed software and verify that the software has not been tampered. The Authenticode technology attaches the X.509 certificate to the .exe and .dll files as well as the digital signature that uniquely identifies an application.
Signing applications or setup packages that you use to install applications from the Web. Examples of setup packages are the .msi and .cab files downloaded from the Internet. Signing the .dll files that the application dynamically downloads from the Internet. Signing the files or installation packages available on File Transfer Protocol (FTP) sites.
When the .cab file that contains the ActiveX component is downloaded and used as part of a Web page, Internet Explorer checks the Authenticode signature of the ActiveX component. Before installing device drivers, Microsoft Windows checks the Authenticode signature of device drivers. If you are using a Windows setup .exe bootstrapper program to launch a Windows Installer (.msi) package, the bootstrapper checks the Authenticode signature of the .msi file.
16
Introduction
When you deploy an application using the Internet or you receive the application as an e-mail attachment, you are not sure of the authenticity of the setup packages that you use to deploy the application. In such cases, you should sign the setup packages using Authenticode to verify the integrity of the setup package and the identity of the publisher. To Authenticode-sign a setup package, complete the following steps: 1. Open the Setup Wizard. 2. Specify the options of the Setup Wizard.
To open the Setup Wizard, perform the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, and then click Microsoft Visual Studio .NET 2003. 2. On the File menu, point to New, and then click Project. 3. In the Project Types list, click Setup and Deployment Projects. 4. In the Templates list, click Setup Wizard. 5. In the Name field, specify the name of the project as MySetup, and then click OK.
To specify the options of the Setup Wizard, complete the following steps: 1. In the Setup Wizard (1 of 4) dialog box, click Next. The Setup Wizard guides you through the steps to sign a setup package. The Setup Wizard (2 of 4) dialog box enables you to choose a project type. You want to sign a setup package in Windows. As a result, you accept the default settings. 2. Click Next.
17
3. In the Setup Wizard (3 of 4) dialog box, click Add. You now need to add the strong-name-signed MyApplication.exe, located in the install_folder\LabFiles\Lab12\Exercise02\Starter\MyApplication directory.
4. Click the application name that you need to sign.
5. Click Open. 6. Click Next. 7. In the Setup Wizard (4 of 4) dialog box, click Finish to add the new project to the MyApplication solution. 8. In Solution Explorer, right-click the name of the project that you created, and then click Properties.
9. In the Property Pages, click the Configuration drop-down list box, and then select Release. The Release option indicates that you are shipping a release build of your product, not a debug build, which is not optimized and might contain unnecessary debug code. 10. Select the Authenticode signature check box.
18
11. In the Certificate file field, type the name of the certificate (.spc file) that you plan to Authenticode-sign, and, in the Private key file field, type the file name that has the private key. Click Next.
12. On the Setup Wizard (4 of 4) dialog box, you can add a timestamp to your setup program. It is good practice to timestamp the setup package as part of the signing process. This ensures that an Authenticode-signed package can be trusted even after the X.509 certificate expires. To timestamp the setup package, in the Timestamp server URL text box, enter the name of the timestamp service provider. 13. Click OK. 14. In the Build menu, click Build MySetup. The result of the operation appears in the Output text box at the bottom. Verify that the project that you created has been built. You can verify that Authenticode signing has been correctly applied to the setup package by navigating to the location where the Mysetup.msi file is created. You can check the properties of the InstMsiA and InstMsiW files to view the X.509 certificate used to Authenticode-sign the setup package.
19
Introduction
You have learned about the Authenticode signing of setup packages. You can also Authenticode-sign an assembly by using the SignCode.exe utility. For example, you can sign 32-bit .exe files, .cab files, .ocx files, and .class files using Authenticode. To Authenticode-sign an assembly with SignCode.exe, you need:
! ! ! !
A user-defined name. An X.509 certificate. A private key used to encrypt a hash digest. The signing authority that issues the certificate, which can be issued either by an individual or a certificate provider. A timestamp (optional).
Authenticode-signing an assembly
To Authenticode-sign an assembly: 1. Launch the SignCode.exe utility. 2. Sign an assembly using Digital Signature Wizard. 3. Verify that the assembly is signed using Windows Explorer.
To launch the SignCode.exe utility, complete the following steps: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, point to Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. At the command prompt, type SignCode, and then press ENTER.
20
After you launch the SignCode.exe utility, you need to sign an assembly using Digital Signature Wizard. To do so, complete the following steps: 1. In Digital Signature Wizard, click Next. 2. Click Browse and browse to the location where the assembly is stored. 3. Double-click the application name in the folder. 4. In Digital Signature Wizard, click Next. 5. Select Custom signing, and then click Next. 6. To select a certificate to which you will attach the private key, click Select from File. 7. Double-click the X.509 certificate that you want to select, and then click Next. 8. To locate the private key file, click Browse. 9. Double-click the private key file name. 10. Click Next. 11. In the Enter Private Key Password dialog box, enter the password and then click OK. 12. In the Hash Algorithm list box, select md5, and then click Next. 13. In the Certificates in certification path group box, select the Only the signature certificate option, and then click Next. 14. In the Description (optional) text box, enter My Authenticode practice, and then click Next. 15. Click Next. 16. On the last screen of Digital Signature Wizard, click Finish. 17. Re-enter the password in the prompt window, and then click OK.
You have Authenticode-signed an assembly. Next, you need to verify that the assembly has been signed. To do so, complete the following steps: 1. Click Start, point to All Programs, point to Accessories, and click Windows Explorer. 2. Locate the MyApplication.exe file inside the install_folder\LabFiles\Lab12\Exercise02\Starter\MyApplication folder. 3. Right-click the MyApplication.exe file, and then select Properties. 4. Click the Digital Signatures tab, click My Certificate, and then click Details. 5. Review the details of MyCertificate.spc. You can verify that Authenticode signing has been correctly applied to the setup package by navigating to the location where the .exe file is created. You can check the file properties to view the X.509 certificate used to Authenticodesign the setup package.
21
Introduction
In this practice, you will use the SignCode.exe utility to sign an assembly with X.509. After signing the assembly you will use Windows Explorer to confirm that the file is signed. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.
Length Instructions
22
7. Select the file MyCompanyCerts.spc from the following location, click Open, and then click Next. install_folder\Practices\Mod12\Practice03\Starter\CertStore 8. In the Private Key dialog box, select the MyPrivateKey.pvk file using the Browse button from the following location, and then click Next. install_folder\Practices\Mod12\Practice03\Starter\CertStore 9. In the Enter Private Key Password dialog box, enter the password as P@ssw0rd, and then click OK. 10. In the Hash Algorithm dialog box, select md5, and then click Next. 11. In the Additional Certificates dialog box, select the Only the signature certificate option, and then click Next. 12. In the Data Description dialog box, enter My Authenticode practice in the Description text box, and then click Next. 13. In the Timestamping dialog box, retain the default state (unchecked) of the Add a timestamp to the data option, and then click Next. 14. In completing Digital Signature Wizard, click Finish. 15. In the Enter Private Key Password dialog box, re-enter the password, and then click OK. 16. Click OK on the message box indicating that the digital signing was successful.
23
Introduction
A strong name provides a way to uniquely identify an assembly. A strong name of an assembly is the combination of the assembly name, the hash digest value that is encrypted using the private key, the version number, and the culture value. The hash digest uniquely identifies the assembly and you encrypt it with a private key. When the assembly is loaded, you use the public key to decrypt the hash value. If the decrypted hash value does not match the original hash value of the assembly, the data integrity of the assembly may have been compromised. Therefore, by using a strong name, you can ensure the integrity of the assembly. However, using a strong name does not verify publisher identity. In addition to using strong-name signing to ensure the integrity of an assembly, you can also use Authenticode signing, as discussed in the previous topics. However, the two signing methods are different in some aspects. The following table compares the two methods.
Supported by Feature Verifying application integrity of application when loaded in Internet Explorer Supporting application executable files, such as .exe and .dll files Providing limited lifespan Providing a mechanism to trust the application publisher Providing compatibility with installation packages, such as Windows Installer (.msi) and cabinet (.cab) files Authenticode signing Yes Yes Yes Yes Yes Strong-name signing Yes Yes
24
Module 12: Deploying Applications with Security (continued) Supported by Feature Verifying application integrity when loaded in Windows Requiring a regular enrollment fee Yes Authenticode signing Strong-name signing Yes
To strong-name-sign an assembly, you use the Sn.exe utility. Sn.exe is a command window utility that provides various options to manage the publicprivate key combination, generate a digital signature, and verify the signature. The following table describes some of the options available with the Sn.exe utility. It is important to note that these options are case-sensitive.
Option -c [csp] Represents Specifies the Cryptographic Service Provider (CSP) to use for strong-name signing. After you specify a CSP, it becomes the default CSP for the computer. Deletes the container specified in containername. Verifies that two assemblies differ only by their signatures. Extracts the public key from the assembly and stores it in outfile. Displays the syntax for the SN command and lists various options of the SN tool. This option provides help for the tool. Generates a new public-private key pair and writes it to the file specified in outfile. Extracts the public key from infile and stores it in outfile. Extracts the public key from infile and stores it in outfile, which is in the .csv (comma separated value) format.
-d containername -D assembly1 assembly2 -e assembly outfile -h -k outfile -P infile outfile -o infile [outfile]
25
Introduction
You have learned that, by using strong-name signing, you can assign a unique name to an assembly and ensure its integrity. If an assembly is strong-name signed, it cannot be duplicated by another assembly. To strong-name-sign an assembly, you use the Sn.exe utility. The steps to create a strong-named application are: 1. Click Start, point to All Programs, point to Microsoft Visual Studio .NET 2003, point to Visual Studio .NET Tools, and then click Visual Studio .NET 2003 Command Prompt. 2. In the Visual Studio .NET command prompt, change the current directory to the directory where you want to create the private-public key pair. 3. To generate a public-private key pair for a file, run the Sn.exe strongnaming tool with the k option as follows:
SN k [filename]
The k option generates a new public-private key pair and writes it to the file specified in filename. For example, the following command generates a public-private key pair in the MySNkey file:
SN k MySNkey.pvk
26
4. Open the AssemblyInfo.vb file in a VB.NET project for the application that you want to strong-name-sign and add the following attribute declaration to the file:
<Assembly: AssemblyKeyFile("[filepath\filename]")>
Adding this declaration strong-name-signs the assembly when you build the assembly. VB.NET will pick the private key from the file specified in filename. 5. On the Build menu, click Build Solution. 6. To verify that the assembly has been strong-name-signed, write the following command at the VB.NET command prompt:
sn tp WindowsApplication1.exe
The execution of the above command displays the public key, which indicates that the assembly has been strong-name-signed.
27
In this practice, you will use the Sn.exe utility to create a private key, MyKey.pvk, and then use MyKey.pvk to sign your application. 20 minutes Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.
4. Using Windows Explorer, browse to either of the following locations: install_folder\Practices\Mod12\Practice04\C#\Starter\MyApplication install_folder\Practices\Mod12\Practice04\VB\Starter\MyApplication Notice that the mykey.pvk file is created in the MyApplication folder.
28
5. Open the solution file MyApplication.sln from either of the following locations: install_folder\Practices\Mod12\Practice04\C#\Starter\MyApplication install_folder\Practices\Mod12\Practice04\VB\Starter\MyApplication 6. Open the AssemblyInfo.cs or AssemblyInfo.vb file by double-clicking it and add the following line to the file after the comment Add the private key information here:
[C#] [assembly: AssemblyKeyFile("..\\..\\mykey.pvk")] [VB.NET] <Assembly: AssemblyKeyFile("..\..\mykey.pvk")>
7. To build the application, click the Rebuild MyApplication option on the Build menu. Now your assembly is strong-name-signed.
29
Review
1. You are planning to deploy an application that has ten features, four of which are optional. Which of the following deployment techniques would you use to deploy the application? a. No-touch deployment technique b. MSI deployment technique c. Cabinet files deployment technique d. XCopy deployment technique
2. You created a local file manager application that manages files on the local computer. The local file manager is granted full access to all files on the local computer. Now, to deploy the local file manager on client computers, you decide to use MSI to deploy the required security settings on the client computer. You will create a security update for which of the following security policy levels? a. Enterprise b. Machine c. User d. Custom
30
3. You have strong-name-signed all the assemblies in your application. Which of the following security risks would still persist if you make your application available on the Internet for deployment? a. Spoofing b. Data Tampering c. Repudiation d. Elevation of Privileges
4. You plan to develop software and make it available on the Internet. You need to ensure that clients who deploy this software are safeguarded through sandbox protection. Which of the following deployment techniques would you use? a. XCopy b. MSI c. No-touch d. Zip file
5. As a software publisher, which of the following techniques will you use to add your identity to a deployment package? a. Strong-name signing b. Authenticode c. Password protection
31
Objectives
Perform Authenticode signing on an application. Perform the deployment of a security policy using MSI.
Prerequisites
The knowledge and skills to create an X.509 certificate using the MakeCert.exe utility. The knowledge and skills to use the SignCode.exe utility to sign an application. The knowledge and skills to use Deployment Package Wizard.
32
Scenario
The student will use the Microsoft .NET Framework 1.1 Configuration to add a new code group and permission set to the machine-level security policy. Student will then create an MSI which will deploy this new machine-level security setting to a new machine. Log on to 2840A-LONDON as 2840A-LONDON\Administrator with a password of P@ssw0rd.
Tasks
1.
Additional information
a.
Add a new code group and permission set to the machine-level security policy using the Microsoft .NET Framework 1.1 Configuration tool. Use Deployment Package Wizard to create an MSI for deploying the machine-level security policy.
For more information about adding a new code group and permission set using the Microsoft .NET Framework 1.1 Configuration, see the following resource: # Module 10, Configuring .NET Security. For more information about creating an MSI using Deployment Package Wizard, see the following resource in this module: # Practice 01: Creating a Sample Security Policy Installer
2.
a.
Deployment Package Wizard, see the following resources: # The Visual Studio .NET Help documentation. For additional information about adding references, in Search, select the Search in titles only check box, then search by using Deployment Package Wizard phrase.
3.
Run the MSI on a computer and check if the security settings are deployed correctly.
33
Tasks
1.
Additional information
a.
For more information about launching the Visual Studio .NET 2003 Command Prompt, see the following resource in this module: # Practice: Creating an X.509 Certificate Using the MakeCert.exe Utility.
2.
Use the MakeCert utility to create a certificate and a pair of public and private keys.
a.
For more information about the MakeCert.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the MakeCert.exe utility, in Search, select the Search in titles only check box, and then search by using the Certificate creation tool phrase. Practice: Creating an X.509 Certificate Using the MakeCert.exe Utility, for more information on creating a certificate using the MakeCert.exe utility.
3.
Convert the CERT file created at the end of the previous step to an SPC file using the Cert2Spc.exe utility.
a.
For more information about the Cert2Spc.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the MakeCert.exe utility, in Search, select the Search in titles only check box, then search by using the Software Publisher certificate phrase. See the Practice, Creating an X.509 Certificate Using the MakeCert.exe Utility, for more information on how to convert .cert files to .spc files using the Cert2Spc.exe utility.
4.
Use the SignCode.exe utility to sign the application in the following location: install_folder\Labfiles\Lab12\ Exercise02\Starter\MyApplication
a.
For more information about the SignCode.exe utility, see the following resource: # The Visual Studio .NET Help documentation. For more information about the SignCode.exe utility, in Search, select the Search in titles only check box, and then search by using the Authenticode signing tool phrase. See Practice 3, Applying Authenticode Signing to an Assembly, for more detailed information about how to sign an assembly using the SignCode.exe utility.
5.
a.
See Practice 3, Applying Authenticode Signing to an Assembly, for more detailed information about how to test the Authenticode-signing process.
34
Course Evaluation
Your evaluation of this course will help Microsoft understand the quality of your learning experience. To complete a course evaluation, go to http://www.CourseSurvey.com. Microsoft will keep your evaluation strictly confidential and will use your responses to improve your future learning experience.