|
|
Access 2003 implements two security features that were not included in prior versions of Access. Both of these features help you manage potentially unsafe code. The Jet SandBox mode security targets Access queries and controls on Access forms and reports. Macro security offers Access developers and their clients the same security against VBA macros that has been available for other Office applications since Office 2000.
The final design of both these features was yet to be determined when this book went to press. However, this section provides general information about the two new security features as a heads up to prepare you for the final implementation of the product and its description in the Access 2003 Help file. In this section you will discover selected code samples and step-by-step instructions that demonstrate how you can take advantage of the new features.
The Jet SandBox helps insure that you do not run unsafe code from queries using the Jet engine or from controls in Access forms and reports. This section describes what the Jet SandBox does and specifically what it blocks. Finally, you learn how to disable and re-enable the Jet SandBox so that you can precisely determine when the Jet SandBox will run on a computer.
Selected commands that you can run through Jet or in expressions on Access forms are potentially unsafe. These commands can pose a threat to the security of the files on a computer. A SELECT statement operating in Jet with the Shell function can run any instruction available from a Command window. Access form controls expose the same vulnerability. In other words, your database applications through Jet and expressions in controls on Access forms and reports can lead to the damage or the loss of files on your computer. The growing use of Jet for Web applications, such as in data access pages, further contributes to the risk of allowing these unsafe commands to be available, such as the Shell function, through Jet and in expressions for control default values and control sources.
The Jet SandBox was redesigned from Access 2002 (http://support.microsoft.com/default.aspx?scid=kb;en-us;294698) so that it could become the default mode for the operation of Jet 4.0 in Access 2003. In the version before Access 2003 Jet SandBox mode was an optional, nondefault mode. In Access 2003, Jet SandBox mode is the default mode, though you still have the option of disabling it. With one exception (the Eval function), the Jet SandBox does not apply to VBA code in a VBA project. In fact, use of Public functions implemented in a VBA project for an .mdb or an .adp file is one way to enjoy the security offered by the Jet SandBox and still maintain the functionality provided by potentially unsafe VBA and Access functions in queries. That is, you can replace references to unsafe built-in functions in queries with references to custom functions designed with VBA code. This VBA code defining the custom function should reside in an Access project with queries that need to reference the custom function.
The Jet SandBox blocks selected VBA and Access functions from executing in Jet queries, as well as any expression in a property, such as the Default Value and Control Source properties, for Access controls. This SandBox action protects your clients from the potentially harmful effects of these actions.
Figure 10-9 shows an Access form with a text box and two buttons. The text box contains the path to the currently selected folder. Showing this path can help someone without authority to map a hard drive—exposing the paths on a hard drive is a step on the way to compromising the security of the files on the hard drive. Form1 also includes two button controls. These controls invoke queries that illustrate other aspects of Jet SandBox operation.
Although showing a path might or might not be a risk, the ability to invoke VBA and Access functions in response to click events is a clear risk. For example, the button on the left in Form1 opens Query1. The query has the following SQL statement, which references the VBA Shell function to run the Calc.exe file from the system32 directory within the Windows folder. While Calc.exe opens only the Windows calculator, the same directory contains many .exe files and related file types, including the disk format utility format.com.
SELECT Shell("calc")
FROM WebBasedList;
Even with the Jet SandBox invoked, you can still run the Shell command along with any of the other VBA or Access functions blocked for Jet queries and control expressions. The workaround to the blocking capabilities of the Jet SandBox requires a Public user-defined function. The Public declaration makes the function available throughout the application, including in Jet queries. The button on the right in Form1 opens Query2. The SQL for this query references a Public user-defined function named MyCalc. The exact SQL string for the query is:
SELECT =MyCalc() AS Expr1;
The VBA code for the MyCalc function appears in Module1 of the Chapter10.mdb file. This user-defined function invokes the Shell function to open the Calc.exe file. In a VBA procedure, the Shell function requires a return value.
Public Function MyCalc()
Dim ret
ret = Shell("C:\WINDOWS\SYSTEM32\CALC.EXE", 1)
End Function
By requiring the movement of code to a module, the Jet SandBox delivers three benefits. First, you avoid the potential risk of users inputting spurious code that can run from the Jet engine. This can happen when you allow a text box on a form to contribute to a SQL string that the Jet engine runs. Second, you can better maintain and manage your VBA and Access code from the VBA project in an .mdb or .adp file than in a Jet SQL window or the Zoom window for control expressions. Third, you gain the new macro security feature described in the next section.
Two rich text files in this book's companion content contain the list of VBA and Access functions blocked by the Jet SandBox (as of the time that I write this chapter). The Table10-2.rtf file includes the full list of nearly 50 blocked VBA functions. The Table10-3.rtf file includes the list of Access functions blocked by the Jet SandBox. The table in this file includes two columns with just over 100 rows. Each row contains an object in the Object column and a property or function of the object in the Property/Function Blocked column. The properties of the objects behave like functions in that they return property values. The Table10-3 list makes it clear that the Jet SandBox applies to both Access database files (.mdb) and Access projects (.adp).
The Jet SandBox operates by default when you install Office 2003. However, you can also explicitly disable and enable the Jet SandBox. The registry key for managing the operation of the Jet SandBox is:
HKEY_LOCAL-MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\SandBoxMode
This registry key can take one of four possible values. The meaning of the settings evolved over the years so that now there are only two possible security states, but there are still four possible settings, which appear below.
0 disables the Jet SandBox in Access
1 enables Jet SandBox at all times
2 disables Jet SandBox in Access
3 enables Jet SandBox at all times
Macro is a generic term used by the Microsoft Office development team to describe programmatic extensibility features. In Access, those feature pertain to VBA code, macro objects, action queries, and SQL pass-through queries. Macro security offers you a means of controlling what programmatic features can be executed by Office 2003 applications. Digital signatures refine this capability and help verify the authenticity of the code in your Office 2003 documents. This section begins with a review of core macro security concepts. Next, it describes the three macro security settings. The section ends with a closer look at digital signatures and how they interact with macro security. An example demonstrates how to use the two concepts together.
VBA macros are procedures and even classes in the VBA project associated with Office applications, such as Access, Word, and Excel. VBA macros are a lingua franca programming language for Office applications and even many non-Microsoft applications. The power and widespread availability of VBA macros contribute to their popularity as a means of spreading viruses. In response, Microsoft offers two means of managing macro security. First, Access 2003 introduces a macro security menu item (Tools, Macro, Security). You open the Security dialog box for this menu item from the menu bar in Access—not from the menu bar in Visual Basic Editor. Access 2003 is the first Access version to implement this feature that has been available for other Office components, such as Word and Excel, since Office 2000. Macro security offers a means of controlling how or if VBA code or other programmatic features, such as action queries or macros, can run in an .mdb or .adp file. Second, you can now digitally sign your code in a VBA project. The macro security feature calls the contents of a VBA project macro code. Digitally signed macro code gives you a means of accurately determining who is the provider of the code in a file. Organizations can use digital signatures as a means of verifying the source of the code in an Office 2003 file, such as an .mdb file. If an organization chooses to enforce the highest level of macro security, digitally signed .mdb and .adp files are the only way for applications to run VBA code or other programmatic features (the next section discusses the three possible macro security settings).
If you have used the macro security feature in any of the other Office components, then you are already mostly familiar with how the feature works in Access files. Macro security in Access applies to VBA macros (code), Access macros, and action queries. In addition, the Jet SandBox can require the migration of VBA code that used to be in queries and Access controls into the VBA project for an Access application. Therefore, macro security interacts with the Jet SandBox because you can now precisely manage how that code operates. Choosing Tools, Macro, Security opens the Security dialog box, which allows you to concurrently manage the functionality of all these objects within an Access application. In addition, digitally signing an Access application file can automatically enable all VBA code even with the highest level of macro security enforced.
There are three macro security settings: High, Medium, and Low. You can expose the macro security settings with the Tools, Macro, Security command. These settings apply to an application, such as Access. Different Office applications can have different macro security settings.
The High macro security setting automatically blocks any applications from running with unsigned VBA projects. The High setting guarantees that a user cannot run any code from an unsigned, untrusted source. The High setting is particularly appropriate for organizations with many desktop and laptop computers that run code supplied by a wide variety of different developers. Although a digital signature does not guarantee that a file is virus-free, the digital signature provides a mechanism for at least discovering the author of any applications containing macros and holding the supplier of an application responsible for its safe operation.
In organizations with a small number of desktop and laptop computers running applications from one or a small number of highly trusted suppliers, the use of the Medium or Low macro security settings may be appropriate. For Medium macro security, a dialog box appears when a user attempts to open an Access database file or Access project with a VBA project. If the project has a digital signature, the dialog box shows a signature identifier, such as to whom the digital signature was issued to. The dialog box also displays buttons labeled Cancel, Open, and More Info. Clicking Open opens the Access database file or Access project so users can run the code in the VBA project. With Medium macro security, users can also choose to enable macros for VBA projects with no digital signature (recall that this is not possible with High macro security).
The Low setting is not generally recommended because no security prompt pops up for Access 2003 applications containing code and all code runs whether or not a file is digitally signed. The Low setting is convenient for experienced developers who are using virus protection software and fully understand the risks associated with viruses. This setting might also be appropriate when a single developer manages all the Access software development in an organizational unit, such as a department or small business. Organizations and individuals selecting the Low setting do so at their own risk. The Microsoft Office development team generally recommends not using this setting.
| Note |
I recommend a Medium or a Low security setting for running the code samples for this book that you download from the Microsoft Press site. The Low security will not remind you with a prompt that you are opening Access files with VBA code. The Medium security setting will remind that your are opening a file with VBA code. If you do use a Low setting, consider using the selfcert.exe program (see the next section) to sign the VBA project yourself and then assign Medium security. The High security setting will not allow you to run the Access database files and Access projects in this book. |
A digital signature binds the holder of the digital signature to a file – much like a traditional signature on a contract binds the person to the terms of a contract. You can digitally sign a document with a digital certificate. There are three broad sources for digital certificates. First, you can create one on your computer. Office 2003 ships with a utility program (selfcert.exe) for creating this kind of digital certificate. A digital certificate created with selfcert.exe is appropriate for testing purposes or for single-user databases because the certificate is only recognized on the computer used to create it. In a sense, a holder self-certifies his identity. Second, you can use the Microsoft Certificate Service as a means of generating valid digital certificates that can be used on any computer. With this approach, a company can generate its own digital certificates. Third, you can obtain a certificate from a firm whose business is issuing certificates and validating the identity of certificate holders. Verisign (http://www.verisign.com) and Thawte (http://www.thawte.com) are two well-known sources that provide these services, but there are others. These firms are called certifying authorities (CAs). Because certification and identity validation demand the expenditure of resources, there is a fee associated with certificates from these firms. However, in exchange, you obtain a third-party validation of the identity associated with a digital certificate. To ensure the encryption for a digital certificate cannot be decrypted in the lifetime of the certificate, digital certificates are normally issued for a specific duration and must be renewed on a regular basis, such as annually.
| Note |
To view a list of sources for obtaining valid digital certificates, go to http://officeupdate.microsoft.com/office/redirect/fromOffice9/cert.htm. |
The certificates have two keys. The private key signs a file with an encrypted code, which acts like an electronic signature. A recipient of the file with a corresponding public key can verify the encrypted code for the electronic signature. If a document is altered by a third party after its signing, the public key cannot verify the electronic signature. The organization issuing the private/public key pairs is responsible for verifying the identity of the individuals to which it issues certificates.
| Tip |
For those who are new to digital certificates and signatures, a particularly friendly explanation of the topic can be found at http://www.youdzone.com/signature.html. |
I close the chapter with a demonstration to make macro security and digital signatures easier to grasp. The step-by-step instructions create a digital certificate, use the certificate to sign a VBA project, and open an Access database file with the signed project. You can start the demonstration by creating a digital certificate with selfcert.exe. Begin by opening selfcert.exe, which you can do with the following command sequence: Start, Programs, Microsoft Office, Microsoft Office Tools, Digital Certificate for VBA Projects. Enter your name in the Create Digital Certificate dialog box. Figure 10-10 shows the selfcert program dialog box with my name entered. To run this demonstration, you need to create your own digital certificate using selfcert.exe.
Next, create a new Access database file named db1.mdb with a sub procedure in Module1 that displays via a MsgBox function "Hello, World!" Then, from the Visual Basic Editor choose Tools, Digital Signature. Click Choose in the Digital Signature dialog box to sign the VBA project with the signature created above. You will be prompted to select a digital signature if more than one digital signature is registered on your computer. Next, Click OK to commit your digital signature to the VBA project and close the Digital Signature dialog box. Save your VBA project to persist your signed VBA project to a storage device. The procedure displaying "Hello, World!" and the Digital Signature dialog box appear within Figure 10-11.
To demonstrate the operation of the digital signature, open a new Access session. Choose Tools, Macro, Security and in the Security dialog box, select Medium macro security. You might receive a prompt to restart Access again for the new security level to take effect. Start a new Access session for the db1.mdb file created as described above. This presents the security warning that appears in Figure 10-12. Click Open to open the Access database file so that you can invoke the code in its VBA project. If you click the check box whose label starts with Always trust files from this publisher, subsequent attempts to open db1.mdb automatically trust the publisher and bypass the Security Warning dialog box. The Cancel button will cancel the file from being opened.
| Note |
Figure 10-12 appears with a Windows 2000 dialog box style, instead of the Windows XP dialog box style like all the other screen shots in the book. In order to get you the most likely Security Warning dialog box for the final version of Access 2003, I had to borrow a screen shot from a remote computer running Windows 2000. |
|
|
