Windows 3.1 PC in multi-user environments

Securing a Windows 3.1 computer in a public multi-user environment by Denny Lin (10/4/95)

One of the design goals of Windows was to provide an operating environment that was easy to use and configure. Easily configurable systems --such as Windows on an IBM compatible computer-- present a very popular problem to public computer systems administrators. For example in a multi-user computer lab, features such as interface consistency and environment security are more important than ease of configuration.

Many public computing systems administrators have tried various approaches to dealing with inadvertent alterations that compromise system usability, and malicious vandals who have the know-how and tools to cause significant system damage. Whenever we installed a highly accessible system, it became hopelessly vulnerable; a password-protected and highly secure environment usually led to a decrease in: a) accessibility, b) ease of use, and eventually c) ease of administration. This is the age old conflict between accessibility and security.

The best strategy seems to be: a) design a formidable defense against inadvertent modifications, without compromising usability; b) design easy to use recovery and damage control measures against determined malicious vandals.

Disclaimer

The author will not be held liable for the misuse of, or the inability to use, information offered here. It is not possible to secure your system against determined malicious vandals. Keep sensitive information away from public computer systems, and make frequent backups of important data. The advice given here applies mainly to users of Windows 3.1 and 3.11 for Workgroups, with DOS 6.22.

Part I: Counter-measures for inadvertent configuration modifications

The Program Manager and important initialization files

The Program Manager is Windows 3.1's desktop manager (unless you have replaced it with another manager such as Norton Desktop). This manager acts as the interface between Windows and the computer user. For better or worse, the behavior of this program can be changed by modifying an initialization file named PROGMAN.INI, found in your WINDOWS subdirectory. You can make these changes with a simple ASCII editor; if you use a Windows based word processor such as Word for Windows, make sure you save the document in ASCII format, or you may not be able to get back into your word processor to correct any errors!

The most important configuration files for maintaining configuration consistency are PROGMAN.INI, SYSTEM.INI, CONTROL.INI, and WIN.INI. These initialization files control among many things, Windows groups and items, access restrictions, file and printer sharing, screen saver settings, wallpapers, color schemes, and default printers.

Before you embark on any changes to your initialization files, back up your current initialization files! You can back up and restore these files using a floppy disk (get a good quality disk) and good old DOS. Switch to your WINDOWS subdirectory, and copy all the .INI files you have.

What follows is a description of initialization files as they relate to the issue of configuration consistency.

PROGMAN.INI

This initialization file offers access restriction control, and prevents inadvertent changes to your public system. Typically, this file contains two sections that define settings and groups found in the Program Manager.

Under the [Settings] section you'll find the SaveSettings variable, which should be set to 0 once you have determined the "best look and feel" for your environment; this prevents users from saving changes to the look of your desktop. The Order variable in this section controls the order of groups in the WINDOW menu, and when a user presses Ctrl-Tab to switch between groups.

Under the [Groups] section, you will find a listing of pointers to some .GRP files used by the Program Manager to display groups. You can hide any groups by removing any undesired groups from the list. If you do so, remember to remove any unused group from the Order variable, found at the end of the [Settings] section.

You can append a [Restrictions] section, where you define the following variables: a) NoClose, which if set to 1, will disable the Exit Windows option from the File menu (Alt-F4 is deactivated too); b) NoSaveSettings, which if set to 1, will disable the SaveSettings option from the Options menu; c) NoRun, which if set to 1, will disable the RUN option from the File menu (this prevents users from running any programs other than those that are on your desktop); d) NoFileMenu, which if set to 1, will disable the File menu altogether; e) EditLevel, which can be set to a number between 1 (low security) and 4 (highest security). The following is an explanation of EditLevel codes:

EditLevel=1 Users may not create/delete/rename groups; can modify items within groups.
EditLevel=2 In addition to level 1, users may not create/delete/move items within groups; can rename an item, change command line (browse), change working directory, and change icon.
EditLevel=3 In addition to levels 1-2, users may not change an item's command line; browsing is deactivated in the item properties dialog box; can rename an item, change working directory, and change icon.
EditLevel=4 In addition to levels 1-3, users may not make any changes to items in groups.

Every one of these variables, when set to 0, will turn their corresponding features off.

While modifying the PROGMAN.INI file offers a fairly formidable way of protecting users from inadvertently changing your public computer's desktop, it does not protect against determined malicious vandals who have access to several back doors. If a user can run a word processor or text processor, and have electronic permission to make modifications to your initialization files, your system is potentially vulnerable.

Example:

Lines marked with (text) are discussed in text

[Settings]
Window=2 4 800 520 3
display.drv=svga256.drv
Order=6 5 4 3 2 1 (text)
AutoArrange=1
SaveSettings=0 (text)
MinOnRun=0

[Groups]
Group1=C:\WINDOWS\MAIN.GRP
Group2=C:\WINDOWS\APPLICAT.GRP
Group3=C:\WINDOWS\ACCESSOR.GRP
Group4=C:\WINDOWS\NETWORK.GRP
Group5=C:\WINDOWS\GAMES.GRP
Group6=C:\WINDOWS\STARTUP.GRP

[Restrictions]
NoSaveSettings=1 (text)
EditLevel=4 (text)

SYSTEM.INI

This initialization file contains among many things, the name of the screen saver Windows will activate, password list pointers that enables a computer to log on automatically to file servers and printers on a network (this is relevant to Windows for WorkGroup users), and computer-specific information (if your computer is connected to some network). The variable that contains the name of the screen saver is found in the [Boot] section, and is called SCRNSAVE.EXE which can point to a screen saver (.SCR) file. If you do not want screen savers, simply set:

SCRNSAVE.EXE=(none)

Some users are known to change file sharing and printer sharing on your Windows for WorkGroups computer. This can cause some serious security problems, because files on those computers could be shared with other computers in the same workgroup. File sharing and printer sharing are enabled and disabled by three variables in the [Network] section called FileSharing, PrintSharing, and EnableSharing, which can be set to Yes or No; automatic reconnection at startup is controlled by the Reconnect variable.

This initialization file is the trickiest to preserve, especially if your computers are connected to a computer network such as Windows for WorkGroups. Several pieces of information need to be unique: UserName, and ComputerName stored in the [Network] section, Hostname stored in the [DNS] section, and the IPAddress stored in your packet driver section. I solved this problem by writing a PASCAL program that looks for those variables in a master copy of the SYSTEM.INI file, and generates a computer-specific copy of the initialization file, from information stored in a look-up table.

Example:

Partial contents of a SYSTEM.INI file
Lines marked with (text) are discussed in text

Lines marked with (specific) indicate computer-specific information (see text)

[boot]
shell=progman.exe
SCRNSAVE.EXE=(None) (text)
:
:

[Network]
FileSharing=No (text)
PrintSharing=No (text)
LogonDisconnected=yes
EnableSharing=no (text)
winnet=wfwnet/00025100
multinet=nonet
UserName=COMPUDYNE_05 (specific)
Workgroup=MICOL
ComputerName=COMPUDYNE_05 (specific)
Comment=
logonvalidated=no
cachethispassword=no
Reconnect=no (text)
PreferredRedir=BASIC

[Password Lists]
COMPUDYNE_05=C:\WINDOWS\COMPUDYN.PWL (specific)
*Shares=C:\WINDOWS\Share000.PWL

[DNS]
DNSServers=192.156.214.1
HostName=COMPUDYNE_05 (specific)
DomainName=lasierra.edu
DNSDomains=

[ms$ne2clone0]
DefaultGateway=192.156.214.23
IPMask=255.255.255.0
IPAddress=192.156.214.205 (specific)
Description=NE2000 Compatible
Binding=ms$ne2clone

CONTROL.INI

This initialization file controls the behaviour and default settings of the Control Panel.

Some love-sick users are known to put "I love you..." notes on screen savers; in worst case scenarios, malicious users can put offensive messages on public computer systems. Some users take advantage of password protected screen savers (such as Marquee) to prevent other users from modifying their messages; the computer is rendered useless whenever the screen saver is activated. Marquee screen saver messages, and passwords used by all password protected screen savers, are stored in this initialization file.

While messages in the [Screen Saver.Marquee] section can be edited by a text editor, the password in the [Screen Saver] section is ASCII-encrypted. If you have access to a text editor or word processor while the screen saver has not been activated, you can: a) remove any characters after Password= in the [ScreenSaver] section, which turns the correct password to a blank entry; or b) set PWProtect=0 in the appropriate screen saver section, which neutralizes the screen saver's password protection. Determine ahead of time what screen saver messages and passwords (if any) you wish to keep.

Example:

Partial contents of CONTROL.INI where none of the screen savers are password protected. Screen saver password is set to blank entry.
Lines marked with (text) are discussed in text

[Screen Saver.Stars]
Density=70
WarpSpeed=8
PWProtected=0 (text)

[Screen Saver.Marquee]
PWProtected=0 (text)
Text=Once upon a time, there was a monk; the monk prayed day and night. He prayed: (text)
Font=Times New Roman
Size=20
BackgroundColor=255 0 0
TextColor=255 255 0
Speed=21
Attributes=00110
CharSet=0

[Screen Saver.Flying Windows]
Density=25
WarpSpeed=5
PWProtected=0 (text)

[ScreenSaver]
Password= (text)

WIN.INI

This initialization file controls among many things, which wallpaper gets displayed, the colors on your windows objects, and which is the default printer.

Wallpaper files are easily created and modified with simple bitmap drawing programs such as PaintBrush; some users with intermediate knowledge about reconfiguring the Windows environment have included funny messages and pictures on public computer systems. Others have changed colors on various windows objects, which in worst case scenarios have resulted in invisible menus and text windows. Finally, all users need access to printers, and many are bound to change the default printer.

Example:

Partial listing of WIN.INI, showing sections relevant to discussion.
Lines marked with (text) are discussed in text

[windows]
spooler=yes
NetWarn=1
NetMessage=No
run=
Beep=yes
NullPort=None
BorderWidth=4
KeyboardSpeed=31
CursorBlinkRate=760
DoubleClickSpeed=900
Programs=com exe bat pif
Documents=
DeviceNotSelectedTimeout=15
TransmissionRetryTimeout=45
swapdisk=
CoolSwitch=1
ScreenSaveActive=1 (text)
ScreenSaveTimeOut=600 (text)
KeyboardDelay=0
MouseTrails=-7
MouseThreshold1=0
MouseThreshold2=0
MouseSpeed=0
DosPrint=yes
device=HP LaserJet 4/4M PostScript,PSCRIPT,LPT2: (text)

[Desktop]
Pattern=170 85 170 85 170 85 170 85
TileWallpaper=0
GridGranularity=0
IconSpacing=75
wallpaper=lake.bmp (text)

[colors] (text)
Background=63 128 255
AppWorkspace=192 192 192
Window=255 255 255
WindowText=0 0 0
Menu=255 255 255
MenuText=0 0 0
ActiveTitle=0 128 128
InactiveTitle=192 192 192
TitleText=255 255 255
ActiveBorder=192 192 192
InactiveBorder=192 192 192
WindowFrame=0 0 0
Scrollbar=192 192 192
ButtonFace=192 192 192
ButtonShadow=128 128 128
ButtonText=0 0 0
GrayText=192 192 192
Hilight=0 128 128
HilightText=0 0 0
InactiveTitleText=0 0 0
ButtonHilight=255 255 255

Part II: Recovery and damage control measures

You can prevent users from modifying your Windows configurations by setting the file attributes of your initialization (.INI) files to read-only. This approach however, disables many important usability features, because Windows often re-writes its own initialization files. If an initialization file becomes read-only, functions related to that initialization file requiring write access will be disabled. For example, if you set your WIN.INI to read-only, your users will not be able to select a different printer because default printer selections are kept in this initialization file.

A smart way to solve this problem is to restore your initialization files everytime the computer is turned on:

Keep standardized original copies of your initialization files in an undisclosed directory (or on a file server if you have a network). Making standardized initialization files do take a good amount of work, but is well worth the effort. Make sure you run exhaustive tests on your standard system before making duplicates of it's initialization files for other computers.
Refresh key files into the WINDOWS subdirectory everytime the computer is booted. This can be accomplished in two ways:
Issue the DOS commands from your AUTOEXEC.BAT file. You can choose to put the original files in the C:\WINDOWS\SYSTEM subdirectory, or some undisclosed and hidden subdirectory. Directories can be hidden using the ATTRIB DOS command.
Issue the DOS commands from a separate batch file, called from your AUTOEXEC.BAT file. This has the advantage of delaying a hacker's attempt, especially if the name of the separate batch file is disguised as CHKDSK.BAT.
If you have a network, implement ways to copy and update standardized key files (.INI, .BAT, etc.) from the file server onto your workstation's hard drives. Key files should be downloaded to the subdirectory you use for refreshing files (in the above example, C:\WINDOWS\SYSTEM). If you don't have a network, invest in an external tape-backup system, and make it a habit to backup your standardized system every month.

Other malicious activity, such as deleting files from subdirectories, can be addressed by using DOS 6.x's undelete sentry. Undelete sentry causes DOS to store all deleted files in a hidden directory (SENTRY), and purges them every 7 days. You can change the behavior of this program by editing the UNDELETE.INI file. Because you want to delay malicious users from knowing what counter-measures you're using, these commands are hidden from the screen by piping the output to the NUL device driver.

Example:

Partial contents of workstation (non-server) AUTOEXEC.BAT files, where the Undelete Sentry is loaded, and key initialization files are refreshed.

@Echo Off
PROMPT $p$g
PATH c:\;c:\dos;c:\windows;c:\menu;
SET TEMP=C:\DOS
LH /L:0;1,45472 /S C:\DOS\SMARTDRV.EXE /X

REM copy progman.ini, win.ini, system.ini, control.ini from the c:\windows\system subdirectory
REM to the windows subdirectory. Replace original copy, and hide screen output
COPY C:\WINDOWS\SYSTEM\PROGMAN.INI C:\WINDOWS\PROGMAN.INI /Y > NUL
COPY C:\WINDOWS\SYSTEM\WIN.INI C:\WINDOWS\WIN.INI /Y > NUL
COPY C:\WINDOWS\SYSTEM\SYSTEM.INI C:\WINDOWS\WIN.INI /Y > NUL
COPY C:\WINDOWS\SYSTEM\CONTROL.INI C:\WINDOWS\WIN.INI /Y > NUL

REM Load Undelete with the Sentry option. Replace original copy, and hide screen output
LH /L:1,52080 C:\DOS\UNDELETE /S > NUL (text)
LH /L:0;1,24336 /S C:\MOUSE\MOUSE
LH /L:1,6384 C:\DOS\DOSKEY

You are visitor number

Main Page | Biography | Project Esther | Computer Tips, Tricks & Tools | Movie Reviews | My Faith | My Car | April | E-mail