Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!midway!ellis.uchicago.edu!dwal
From: dwal@ellis.uchicago.edu (David Walton)
Newsgroups: comp.sys.mac.misc
Subject: Re: Resedit and FileGuard
Message-ID: <1990Aug5.050947.610@midway.uchicago.edu>
Date: 5 Aug 90 05:09:47 GMT
References: <4141@dogie.macc.wisc.edu>
Sender: news@midway.uchicago.edu (News Administrator)
Organization: U. Chicago Computing Organizations, Academic and Public Comp.
Lines: 73

In article <4141@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, 
MACC) writes:
>In article <1990Aug3.163157.28701@midway.uchicago.edu>, 
>dwal@ellis.uchicago.edu (David Walton--me) writes...
>
>-Any experienced user, however, can generally break security without
>-ResEdit: the easiest tool to use is a System disk.  Boot the machine
>-with a floppy, and viola, all of the protective INITs and cDEVs don't
>-do anything. 
>
>Sorry, Wrongo, read on...
>
>You might want to try FileGuard out before saying stuff like this. 
>FileGuard will effectively and completely prevent someone from accessing 
>a protected volume, *even if they boot off a system diskette!*. When you 
>boot a mac from a system diskette and the FileGuard protected volume 
>mounts you will be asked for a password. If you don't have it the volume 
>won't mount and is inaccessible, even from HD Setup--for those who would 
>be so perturbed at such protection that they would attempt a low level 
>format.

On your advice, I looked at it.  You're right.  Mea culpa.

I've always been curious how security systems manage to do this.  I
assume that it's done by patching the device's SCSI driver.  FileGaurd
appears to install a Notification Task from the driver which prompts
for the password (and masks the interrupts so that it's not possible
to get into the debugger).  Presumably what happens is the Open call
sets a flag somewhere in the driver's private storage so that the
first Control (or Status?) call installs the request, and the NM
Response procedure clears the aforementioned flag, signifying that the
driver can then respond normally to calls, and the driver posts
a disk-inserted event so the startup application can mount it.
In pseudo-code,



  case drvrMessage of
	open: ...
		userCleared:=false;
		doMount:=true;{  assume we should mount it }
		notificationPosted:=false;
	      ...

	control: ...
		if doMount then
	 	  if not (userCleared) then
		    if not (notificationPosted) then
		      begin
			NMInstall(...);
			notificationPosted:=true;
		      end
		    else
		      if (notificationRecvd) then
			doMount:=false;
		   else
		    {  Handle control calls normally  }
		     ...
		     PostDiskInsertEvent
		else
		  {  Sorry, bucko, you're hosed  }


If this assessment is wildly (or even mildly) inaccurate, could
somebody explain in general how the protection might be implemented?



--

David Walton		Internet: dwal@midway.uchicago.edu
University of Chicago   {  Any opinions found herein are mine, not  }
Computing Organizations {  those of my employers (or anybody else). }