Windows Vista has several mechanisms to improve security. One is Authenticode technology, i.e. the use of certificates and digital signatures; see the first screenshot.

Another is User Account Control or UAC, i.e. limitation of access to protected areas of the system. When you try to run a program which requires this access, you have to supply administrative credentials; see the second screenshot.

Microsoft documentation

The official Microsoft document on these features is Windows Vista Application Development Requirements for User Account Control Compatibility, filename WindowsVistaUACDevReqs.doc.

Below, we shall mention some command-line utilities for code signing. For these tools, the MSDN website also has reference manuals, which describe all the options and include some sample invocations.

I am not going to give any explicit URLs to Microsoft pages or downloads because they change so often. Search e.g. by filename.

Some tests

Some legacy utilities

The legacy programs (an editor, a filemanager and an image manipulation program) that I tested produced warnings The publisher could not be verified. when they were on a network drive (see the first screenshot), but not when they were on a local drive, and not when invoked from the command-line, whatever their location. Can this really be true?

A home-made installer

I also tested an installer that I had written in NSIS. As expected, I got the security warning below:

Publisher not verified warning

After clicking away this warning, another dialog popped up, informing me that an unidentified program from an unidentified publisher tried to access my computer, and asking me to provide administrator credentials:

Admin credentials prompt

This second dialog shouldn't have occurred, since this installer only accessed user settings and user-owned areas of the filesystem. Simply because the program was called install.exe, Vista assumed that it would access protected areas, so it requested administrative credentials.

ActiveState Perl (zip file installation)

I installed ActiveState Perl as a regular user from the zipfile installer. I started the actual installer, a batchfile Installer.bat, from the command-line. No warnings popped up beforehand, although at the end I got warnings

Couldn't register PerlScript engine
Couldn't register Perl eventlog message catalog
Unable to update PATH in registry: No such file or directory

These warnings were caused by the installer trying to edit the system part of the registry (HKEY_LOCAL_MACHINE hive) and went away when I ran Installer.bat from an administrative command-prompt.

Running as administrator

You can log in as a regular user and still become administrator from within your session. You can e.g. start an administrative command prompt by right-clicking the command-prompt icon and choosing Run as administrator:

Run as administrator option

Note. By default, the command prompt is in the Accessories submenu, not right under the start menu as in the screenshot.

Warning. If you supply administrative privileges to run a program, then you suddenly have the network connections of this administrative account instead of your own. This creates an interesting Catch-22 if the program tries to access the user's network home. Conclusion: it is a bad idea for installation programs to mix system setup and user setup.

Adding digital signatures

It is possible to add digital signatures to existing executables. All the required files (command-line utilities makecert.exe, pvk2pfx.exe, signtool.exe and a library capicom.dll) can be found in Microsoft Platform SDK for Windows Server 2003 R2, which can be downloaded for free from the Microsoft site. The computer with which you do the download must be running a WGA-enabled version of Windows.

Copy all these files to one directory and work from there. These utilities should work on Windows 2000 and later, and may require administrative privileges.

If you bother at all with digital signatures, then you have the choice of generating a certificate for internal use yourself or to get an official certificate. Microsoft has a webpage Microsoft Root Certificate Program ... listing participating member CA's (Certificate Authorities) who issue such certificates.

In theory, you should be able to create a do-it-yourself certificate with the OpenSSL command-line utility. However, I couldn't get Vista to accept such a certificate as a valid self-signed certificate when using it for a digital signature. That doesn't mean that it can't be done; I am not an OpenSSL expert. But since you need a Microsoft tool for code signing anyway, you might as well also use the Microsoft tools listed above for generating a certificate. As indicated earlier, you can find documentation on these tools on the MSDN website.

Telling Vista what privileges are going to be required

If Vista thinks that a program is going to modify protected parts of the operating system, you need to provide administrative credentials beforehand. It may be better to tell Vista explicitly whether or not these credentials are required. This can be done with a manifest like the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="*"
    name="install"
    type="win32"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

where name should be the name of the executable minus extension, and the value for requestedExecutionLevel can be asInvoker, highestAvailable or requireAdministrator.

Microsoft development tools let you embed such an xml manifest into the executable. If your software cannot do that, then you can instead place a manifest as a separate file in the same directory. For an executable install.exe the name of the manifest file woud be install.exe.manifest.

Microsoft warns in the WindowsVistaUACDevReqs.doc document listed below:

Note
In future releases, the ONLY way to run an application elevated will be to have a signed application manifest that identifies the privilege level that the application needs.

The latest version of NSIS has support for requestedExecutionLevel. I merely needed to add a statement RequestExecutionLevel "user" to the source of my home-made NSIS installer, and this took care of the misplaced request for admin credentials described above.

The homemade installer revisited

With a manifest, the NSIS installer listed above worked fine. A similar installer which did a system install was somewhat broken, since it mixed user setup and system setup, but still could be made to work.

My portable TeX scripts

A quick test indicated that my VBscript installers for a portable MikTeX and TeX Live produced working versions of [pdf]latex and dvips.

A few tidbits

The test machine

I installed Vista Business Edition in a VMware 5.5.4 WS virtual machine under Ubuntu Feisty. The virtual machine has an expandable 20GB hard disk and 1GB of memory.

I didn't do too much configuration besides turning off eye candy, because I was trying to find out what a regular user would run into.

The virtual machine communicates with the host via a host-only virtual network. It is virus- and spyware protected by not having access to the internet. The downside is that this interferes with the verisimilitude of my testing.

 

Copyright (C) 2007 Siep Kroonenberg
siepo at cybercomm dot nl

Last revised on July 22 2007