On Thursday, March 3, Brian Baker asked about methods of controlling
access in a Windows environment. The following message was posted
to PACS-L in January. I thought it would be of interest to the list.
I am forwarding it with the original poster's approval.
Forwarded message:
> From daemon Tue Jan 4 16:55:20 1994
> Message-Id: <199401041655.KAA27988@whale.st.usm.edu>
> Date: Tue, 4 Jan 1994 10:01:12 CST
> Reply-To: Lee Jaffe <jaffe@scilibx.UCSC.EDU>
> Sender: Public-Access Computer Systems Forum <PACS-L@UHUPVM1.UH.EDU>
> From: Lee Jaffe <jaffe@scilibx.UCSC.EDU>
> Subject: Windows security
> To: Multiple recipients of list PACS-L <PACS-L@UHUPVM1.UH.EDU>
>
> ----------------------------Original message----------------------------
>
> I put out a call about a year ago asking for help with setting up
> Windows-based applications for public access. My concern focused on users
> having access to Windows' other functions, including the ability delete
> and rename files and run other applications. Last week, I finally was
> called upon to install the application (OED2) that prompted my request.
>
> I managed to find two of the responses I received a year ago and these,
> along with the assistance of two colleagues here, was able to make an
> apparently secure installation. One of the messages referred me to the
> following article, but the journal has been cancelled here.
>
> User group tip: safety in Windows.
> PC World v10, n12 (Dec, 1992):352.
>
> I was able to track down two other articles that provided very good
> information. The first,
>
> Tweney, Dylan.
> Lock your desktop.
> PC-Computing v6, n4 (April, 1993):258
>
> suggests editing the PROGMAN.INI file to restrict access to its features.
> To do this, add the line [restrictions] to the end of the file and
> indicate what you want to restrict below that.
>
> NoRun=1 means no access to the RUN command
> NoFileMenu=1 no FILE menu
> NoSaveSettings=1 prevents saving settings
> EditLevel=1 no creating,deleting, or renaming Program Manager groups.
> EditLevel=2, " or program items.
> EditLevel=3, " plus no changes to a program item's command line.
> EditLevel=4 prevents all changes to groups or program items.
> NoClose=1 can't exit Windows once it's been started.
>
> The second article,
>
> Grech, Christine.
> Take control of the Control Panel.
> PC-Computing v6, n3 (March, 1993):228.
>
> shows you how to lock up Control Panel features. To do this edit the
> CONTROL.INI file. At the end of the file, add [DON'T LOAD] on a new line.
> Below that, type the names of the icons you want to disable followed by
> either =1 or =0. This also removes them from the Settings menu.
>
> The second message I saved suggested changing the shell= line in Windows'
> SYSTEM.INI file to the name of the application you plan to use. The
> normal entry is shell=PROGMAN.INI which would open then PROGRAM MANAGER
> when the application was quit. Changing the shell= to the application
> name meant that quitting the application also quit Windows.
>
> It ended up that we worked on several different installations the same
> day, experimenting with different parts of the above and adding a few of
> our own. For instance, the others suggested starting by deleting the
> icons of any applications or utilities (such as games) that we wished to
> block. We then used a selection of the PROGMAN.INI entries:
>
> [restrictions]
> NoRun=1
> NoFileMenu=1
> NoSaveSettings=1
> EditLevel=4
>
> For the OED2 installation, I ended up going to the extreme of editing the
> SYSTEM.INI file. You have to be careful to give full path and file names.
> SYSTEM.INI is in the \windows directory and OED2 is in the \oed directory
> so the line had to read shell=c:\oed\oed.exe before it would work. The
> apparent drawback to this approach is that it seems to work for only one
> application, ever, total. If I had another Windows program that I wanted
> to run, it wouldn't work. (I haven't looked into the possibility of
> creating different SYSTEM.INI files for each application and storing them
> in different subdirs but ....) One of the real strengths of this approach
> is that when you have only one Windows application running at a site, it
> is a lot cleaner than anything else. (Otherwise, when you quit the
> application, the user ends up looking at the Windows desktop,wondering
> what to do next.)
>
> One caveat: Make backups of any files you might edit before you make
> changes. This makes it easier to recover when things go wrong.
>
> All the above is predicated upon the use of some sort of menu system.
> Security in Windows means little if the users have direct access to DOS
> commands. The menu, for instance, launches the individual applications
> and it is important that the applications themselves don't have any
> security holes and that quitting the application gets you back to the
> menu.
>
> I'm a Windows non-user so you can gauge how little expertise is needed to
> pull this off. You also can't count on me to provide much more help than
> what I've laid out here. But if you have any questions or comments, I'll
> try to respond.
>
>
> -- Lee Jaffe, UC Santa Cruz
>
Scott Salzman (912) 752-2625
Systems Librarian
Mercer Univ. Law School Library
salzman_sd@mercer.peachnet.edu
This archive was generated by hypermail 2b29 : 03/09/00 PST