There are a number of security holes in DP4:
Malicious users with access to DP4 programs can copy their own programs onto a server running TCPMGR using NETCOPY and then start them running one way or another. On Windows NT they can also use NETCOPY to access files that are supposed to be denied to them. These problems can be addressed by making simple changes to how TCPMGR is started, or by configuring DP4 to run in an account with less privilege that the local system account that is normally used by the DP4 service.
A malicious program could take advantage of a security hole present in programs such as DP4SRVR.W32 and TCPMGR.W32 to bypass normal NT security features and install anything it wanted as part of the operating system. Such an infection might go unnoticed for a long time. Such a program would not need to know anything about DP4, only something about how to look for and exploit security holes, so they almost certainly exist.
The only mitigating factors for this problem are that the malicious software would already have had to gain some access to the machine, and that quite likely it would find something other than DP4 it could use to make the infection more severe anyway. This problem is fixed by DP4 Enterprise and a fix will be issued for existing systems as well.
The options described in this section are easy to implement and can be used in any envionment, including Windows 9x and Unix. The command tails described are all new in version 4.620.
From 4.620 TCPMGR no longer permits commands to start programs on the server by default (this facility is required by DP4 Terminal Server). To enable the facility specify -allow_execute on the command line to for tcpmgr.
It is possible to disable support for the sf_open() command (and hence all DP4 remote file operations). DP4 remote file operations bypass NT security unless you go to the considerable trouble of implementing the NT security features described below. There are two mutually exclusive command tail options:
Note that either of these options will prevent some DP4 programs from working over a network, notably DBBACKUP, DBCHECK, DBRECOV, DBRESTOR, DYNABACK, REORGDB, and the option to create a new database in MAKEDB (though they will work using DP4 Terminal server if enabled)
For DP4 Terminal Server you are recommended to use the -rocopy command tail to completely prevent a file being copied onto the server and then executed. -nocopy is not recommended because it will stop graphics being displayed.
The contents of this section are preliminary documentation only.
DP4 Enterprise can be run in an account with less privilege than the local system account, which is the account normally used for services. With earlier versions of DP4 this did not work well because it was hard to diagnose problems.
The basic idea is that DP4SRVR.W32 and TCPMGR.W32 run some of the time using a special logon, and that permissions on the machine should be set up to limit what this logon can get to, but that the DP4 service as a whole still uses the local system account so that it can interact with the desktop, and produce diagnostics properly.
For this to work you have to be running on Windows NT 4,2000, or XP (Server or Workstation). It is advisable to use the latest service packs available, especially on Windows 2000, as it is possible to render a Windows 2000 machine non bootable through making the boot process get an access denied error! Windows 2000 SP2 appears to set default permissions to much more sensible values than used in earlier versions. To run DP4 securely it must be run as a service in the local system account, allowed to interact with the desktop (the default), otherwise you will most likely get access denied errors, especially if you use DP4 Terminal Server.
You must test on an identical machine and configuration to the live configuration if you plan to run DP4 securely. The slightest difference in the way the machines are set up or the version of Windows might mean you get an access denied error on one and not another.
All hard drives should use NTFS as other file systems do not allow permissions to be set. You can use the CONVERT program to convert existing FAT/FAT32 partitions non-destructively. e.g. convert c: /fs:ntfs.
Initially NTFS partitions may well be set with permissions that allow Full Control to Everyone (at least up to W2K SP2).
Changing permissions so that things work securely is much more complex than might first appear, especially in the \windows directory. The problem is that there is a lot of badly behaved software that wants to create temporary or scratch files in critical directories such as the system32 directory, but which does not give a helpful diagnostic when given an access denied error by the operating system. For example it is difficult/impossible to get active desktop working properly for an ordinary user on a Windows NT machine after setting security, for just this reason. The built in tools for managing access control are barely adequate, though things are somewhat better on Windows 2000 than before.
If you are serious about using NT security to control access to files you should probably invest in suitable third-party software or literature that tells you how to go about it. Roughly speaking , you need to ensure that administrators, SYSTEM, and CREATOR OWNER have full control everywhere, but that ordinary users are much more restricted, for example EVERYONE should be very restricted indeed. You can use DENY Access control entries restrict access to certain files or directories for specific users.
Using DFSETUP change the layout of DP4 so that all the files are stored in one directory hierarchy such as C:\DP4 and subdirectories DB,WIN,TMP,PRNS. Change the directory for debug.out in the DP4 configuration file so that it goes to the PRNS directory:
[errlog]
debug_filename = ..\prns\debug.out
Create a local user with a name such as DP4USER. Make it a member of the guests local group, allow it logon as a service access, and for good measure deny allow interactive logon (though this might just cause a problem, and should not really be necessary, as guest accounts can't do much damage).
Give this user Full Control access to C:\DP4 and subdirectories (for folders only), and read write but not execute for files. Then change the access in C:\DP4\WIN to be Read and Execute only for files.
You could use DENY permissions on some other directories to restrict DP4 further without upsetting anything else. It should be noted that having long ACLs on files can impact performance.
Add the logon details for DP4USER to the [win32] section of the DP4 configuration file like this:
user=DP4USER
password=password
domain=.
Once you do all this dp4srvr.w32 will run impersonating DP4USER which will mean it can only access files this user can, and any processes created by TCPMGR will be run as this user as well. TCPMGR runs as itself most of the time, as otherwise it can get WINSOCK errors, presumably because some internal file cannot be accessed.
You can use secure=0 in the [dp4srvr] or [tcpmgr] sections of the DP4 configuration file or -secure=0 on the command line to dp4srvr.w32 or tcpmgr.w32, to disable impersonation for one or other of the programs.
As well as the security of the DP4 service itself you may be concerned about the type of account your application that uses DP4 will run in. Prior to 4.620 there were some problems running DP4 programs in a non-administrative account. However, since 4.620 there should be no problem with doing this. DP4 has been tested running like this on Windows 2000,XP and Windows Server 2003.
Nevertheless there are some points to bear in mind: