Security architectures for textual databases

Computers & Security, 9 (1990) 621-630

Security Architectures for Textual Databases Claude Laferriere*, Gordon G. Bell

G. Owen Higginson

and

SHL SystemhouseInc., Ottawa, Ontario, Canada

Security requirements and concepts have already been applied to operating systems, networks and, more recently, to relational database management systems. There are other functions, however, whcrc security is also a concern such as r&wing information from unstructured databases. This paper focuses on security archirccrurcs for databases containing textual information. The security rcquiremcnts of textual databases arc investigated and architectural configurations arc inrroduccd. Profiling opcrarions arc also discussed. Keywords: Multi-lcvcl architecture.

secure

text DBMS, Text DBMS, Security

1. introduction 1 .I.

Secure

Systems

amount of work has already been considcrablc done in security cnginccring to dcfinc basic security principles and models and to dcrivc a set of consistent security rcquircmcnts. Central to thcsc efforts, wcrc the initiatives of the U.S. National Computer Security Ccntcr (NCSC) which produced the Trusted Computer System Evaluation Criteria (TCSEC) [l] and its Trusted Network Intcrprctation (TNI) [2]. The NCSC is currently working on a Trusted Database Intcrprctation which should bc soon (TDI) of the TCSEC rcleascd. From a systems integration point of view,

A

‘Prcscnt Ortawa.

address: Comgatc Engineering Onrario K2P OG5. Canada.

Ltd., 331 Cooper

1990, Elsevier Science Publishers Ltd.

Street,

little attention has been paid, thus far, to other information processing functions which should also bc used in a sccurc fashion. Of particular interest to a large group of users arc unstructured database managcmcnt systems, often rcfcrrcd to as Textual DataBase Managcmcnt Systems (TDBMS). In that category, one finds products such as TOPIC from VERITY [3], FUL/ TEXT from FULCRUM [4], STAIRS from IBM [5], as well as many others. Thcsc TDBMS provide for the quick and timely rctricval of information from unstructured databases and, although using storage objects rccognizcd by the operating system, introduce their own sccuriry problems. This paper conccntratcs on the security aspects of TDBMS and, in particular, on their integration within a sccurc system. The paper also covers the aspect of profiling operations whcrcby users specify sclcction profiles which arc applied against newly arrived material in order to inform users of new, rclcvant information. 1.2

Assumptions

In its investigation of sccurc TDBMS, this assumes the cxistcncc of a trusted operating providing TCSEC, B-lcvcl mechanisms and ancc. This implies that the trusted operating supports mandatory security and storage

paper system assursystem object

621

C. La ferriere et al. ISecurity

Architectures

labclling. Security is also taken in its narrow of confidcntialiry as d&cd in ref. [ 11.

scnsc

1.3 Outline

This paper is divided into three basic sections bcsidcs this introduction: Section 2 investigates TDBMS from the point of view of their indexing and starching functions. It also covers the security aspects of thcsc two functions. Section 3 covers the profiling operations and introduces rcquircmcnts ncccssary for sccurc profiling. An architccurc is also prcscntcd. Section 4 prcscnts some concluding remarks.

2. TDBMS

Principles

of Operations

As dcfincd informally in the previous section, a TDBMS comprises a given amount of unstructured information and of tools to provide for the easy and quick rctricval of that information based upon user-gencratcd qucrics. For cxamplc, the cntirc tax laws and tax guidclincs of a country could bc stored in clcctronic format on computer disks and through appropriate software (i.f>. part of the TDHMS) users could formulate qucrics and have the TDBMS rctricvc the rclcvant portions of tax manuals whcrc the clcmcnts of the query wcrc found. To make the cxamplc more realistic, consider a user with two children, one of which is in day cart; that user may enter a query of the type:

for Textual Databases

turcd databases is the file. The scope of the starch can bc the cntirc database or can be constrained to only a subset of all the documents. Scvcral architccturcs and tcchniqucs exist to organize the data and to circumscribe the domain of a query. Thcsc points, as well as other fcaturcs of commercial products, do not have a direct impact on security architccturc and will not bc covcrcd. The intcrcstcd rcadcr is cncouragcd to look at systcmspecific information to clarify implementation questions. 2.1 TDBMS Concepts

As mcntioncd bcforc, the basic unit of information in a TDBMS is a file. Typically, a file will contain an cntirc document or a smaller portion such as a chapter. The main function of a TDBMS is to cnablc users to search the database with qucrics made up of word patterns. Howcvcr, searching for the prcscncc of patterns through a large unstructurcd database can bc cxtrcmcly time consuming, negating the advantages of being able to search. For this reason, modern TDBMS prc-process their data so that subsequent starching is made very much faster. There arc, thcrcfore, two main functions to a TDBMS: which prcparcs Indexing, scar&cd speedily by gcncrating in the form of inversions; and

(1)

the files to bc extra information

(2) Searching, information (ix

In the above query, the system would starch for occurrcncc ot those three terms in all the documcnts in its unstructured database and report on the number of hits it found. In this cast, a hit is an indication that the pattern was found at least once in a particular document. Typical TDBMS systems would then give the user the option of viewing the A. d ocumcnts ot intcrcst.

ing ftmction a rcasonablc

Many, if not most, TDBMS USC operating system files as the basic container for documents; in other words, the basic unit of information in unstruc-

22.1

622

which uses the extra road map inversions) produced by the indcxin order to rctricvc the information in time.

The workings of those two functions and, in pax ticular. their security bchaviour, arc the topics of the next section. 2.2 TDBMS General

Functions

Definitions

In order to introduce the indexing and starching functions, it is ncccssary to dcfinc some of the

Computers and Security, Vol. 9, No. 7

elements

ing function,

of the system. The set F

(2.1) where f; is an individual file and contains all the files which comprise the unstructured database. For ease of data handling and data management, some commercial systems define the set F in terms of other smaller sets F,, j= 1, . . . , x, such that

I, can bc d&cd

o:w-J;x

I: Lb; -Fx

as

such that a word in M’, is linked file in F. The set 0 is defined as

O={o,,

o2

(...,

0, ]

(2.5)

0,

to an offset to a

E (Intcgcrs}

(2.6)

where each O,is an offset to a word in a file. F=F,

U F, U ,...,

U F,

(2.2)

and where (2.3) From a security analysis perspective, it is casicr to consider the case of eqn. (2.1); the results arc easily extrapolated to the formulation of cqn. (2.2). The information contained in F is composed of words, w, which are part of W, the set of all possible words in a given language. For convcnicnce, another set, W,. , is defined as

w,.={wEWI:‘3f;EF(wq}

(2.4)

The set W,.. is therefore the set of all the words which arc to bc found in the files of F and is a subset of W (i.e. IV-C W). The set IV,: is useful in defining the indexing function but it should be cmphasizcd that the origin of all the search patterns that users may submit to the TDBMS is in the set W. In this paper, the starch patterns will bc assumed to be composed of single words. In reality, supported by TDBMS arc search patterns composed of several words linked by conjunctions, disjunctions, negations, and proximity indicators. This rcstrictivc assumption facilitates security analysis without invalidating its conclusions. 22.2

indexing

Indexing is a preparatory function which a TDBMS would perform on its unstructured data in order to speed up the search function. The indcx-

From a security pcrspcctive, the elements of F arc individual files which arc objects of the trusted operating system. As the trusted operating system is assumed to bc a TCSEC B-lcvcl system, each file will have its own security label and will be managed by the operating system in a manner consistent with the rcquircmcnts of the TCSEC. In practical situations, the result of the indexing function is an index file which, as indicated in cqn. (1.5) contains a list of words corresponding to the set U’, and offsets to files in which thcsc words have been found. The indexing function of cqn. (2.5) has been simplified not to cater to multiple occurrences of a word in the same file. Another aspect of indexing which has not been captured by cqn. (2.5) is that of stop lists. Thcsc lists are composed of common words (o,~. and, or, to, the, it etc.) which do not have to be indexed. The savings in processing time and disk space arc substantial. As thcsc stop lists do not contain any scnsitivc information, they are assigned a system_low label and arc therefore acccssiblc by all other proccsscs. Assuming that the files of F arc at diffcrcnt security lcvcls, the indcxing information will span multiple Icvcls. Although the words themselves and their offset into files of F arc not necessarily scnsitivc, they may contain information which should not be divulged. It would thercforc seem rcasonablc to run the indexing process at a system-high lcvcl or, at least, at the highest lcvcl of any of the files in F. The security architccturc of such an indexing process is shown in Fig. 1. Although the indexing process can run as a single-lcvcl process in a special compartment, the search process will have to be

623

C. La ferriere et al. /Security Architectures

for Textual Databases

Fig. -3. Mulri-lrvcl Fig.

I, Single-lcvcl

indexing

indexing

architccturc

archirccturc.

trusted as it will be called upon to interpret the contents of the indexing information for a user at a lower security lcvcl. This is also illustrated in Fig. 1.

tivc information. It is thcrcforc at a systcm_low lcvcl whcrc it can bc used by all other proccsscs. 2.2.3 Searching

A diffcrcnt organization for the frlcs in F was suggested in cqn. (2.2). It is intcrcsting to note that separating the files into a subset of files at the same security lcvcl and running the indexing function against each of those subsets crcatcs a situation in which trusted proccsscs do not have to bc used for starching since each group of files in a security compartment has its own corresponding index file. This type of architccturc is shown in Fig. 2. In that figure, it is also intcrcsting to note that as many index files arc produced, thcrc has to bc a means of keeping track of their number and location. This is usually achicvcd through the USC of an index list (or a global index). This new file, which only contains pointers to index files, does not contain scnsi-

624

Starching as a function and is defined as S:W-FX

o:w-_f;xo,

is very similar

to indexing

(2.7)

The only diffcrcncc with indexing is that the total starch space is rcprcscntcd by the set W instead of IV,.. This is not really significant since scarchcs for non-cxistcnt patterns map into the empty set, 0. As well, it should be rcmcmbercd that the search function of cqn. (2.7) is a simplification of what is offcrcd by commercial TDRMS. These support more complex starch patterns than is indicated by cqn. (2.7) and thcsc complex patterns may occur more than once in any given file.

Computers and Security, Vol. 9, No. 7

process certainly has to bc trusted when the user’s label is lower than that of the index file. The latter case is likely to be more frcqucnt.); and l In the case of the architecture of Fig. 2, the search process is always at the label of the initiating user and is permitted access to the index files which have security labels dominated by that of the starch process.

Fig. 3.

Itldex data structure.

2.3 Architectural Considerations In actual systems, words, files and offsets arc all linked in a special structure such as the one shown in Fig. 3. In that figure, words are shown to be linked to a set of files, and for each file thcrc arc offsets at which the word is to be found. As mentioned before, this index structure does contain information about the contents of the files and, although not of the same sensitivity, the contents of the index structure may reveal information about the files that have been indexed. For this reason, it may bc prudent to set the label of the index structure to be the same as that of the label of the most scnsitivc file to have been indcxcd, as illustrated in Figs. 1 and 2. From the point of view of a starch operation initiated by a user, scvcral security conditions have to be met: l As it is initiated by a user, the starch process will run at the same security label as that of the user; l The security label of the starch process has to dominate the security label of the index file (or files, dcpcnding on the architccturc); l In the cast of the architccturc of Fig. 1, the starch process has to bc trusted as it has to bc able to read the indcx file and write to the user at the same time. (Note: while the scar& process dots not have to bc trusted when the label of the index file and that of the user arc at the same level, the starch

As far as the functions of the search process arc conccrncd, it should bc cmphasizcd that all the necessary information is already in the index file (or files). In cast of a complex starch, the starch process handles the extra complexity. For cxamplc, a query composed of a list of words linked by “and” conditions (i.e. conjunctions) could process each word scparatcly and then apply the conjunction. Similar techniques can bc applied for other conditions as well as for word proximity scarchcs (such as word 1 within so many characters of word 2 or within the same scntcncc). As already discussed, the TDBMS deals with objects which arc known to the trusted operating system and which arc thcrcforc protcctcd by the latter. This indicates that the trusted operating system provides the ncccssary protection for the text f&s and performs mandatory access controls on those files based on their security classification and on the clcarancc lcvcl of the users. Howcvcr, the contents of the index f&(s) arc also scnsitivc and it is rcasonablc to assume that the result of a starch should not contain mentions of files for which the originator of the query has no mandatory access privilcgc. A suitable security mechanism has to bc in place to cnsurc that users will only see files with security labels dominated by their clcarancc lcvcl. 111other words, given a user, U, with a clcarancc l~~cl. C(U), and a query result, K, the following condition should hold: C&:)X(_/-).

V_f-I_f-EK

(2.8)

whcrc L( /‘) corresponds to the security label of file f: The structure of security labels and of clcarancc

625

C. La ferriere et al. /Security Architectures

levels includes a hierachical component (i.e. level) and a set of categories which arc non-hierarchical. The symbol > denotes dominance as dcfincd in ref. [I]. As well, the query result, R, is defined as

R={J;,_f;+,mf;+,,l.

(2.9)

In order to satisfy eqn. (2.8), security filtering will have to be pcrformcd on cithcr the index file or the This is called pa-jltering or postqLlery result. f;:lterinS and corresponds respectively to point A and point B in Figs. 1 and 2. 2.3.1

Pre-filtering

Prc-filtering involves removing rcferenccs to files in the index structure for which eqn. (2.8) does not hold. In that fashion, the search process only deals with files for which the originator of the query has mandatory access permissions. As can bc seen from Fig. 1, the single-level indexing approach dcpictcd therein dots not lend itself well to pre-filtering: (1) The size of the index file may bc considcrablc and prc-filtering would bc an expcnsivc and lengthy operation (usually, 1RI 4 IIndcxl and it thcrcforc makes more sense to USC post-filtering with single-level indexing architecture); (2) Changes in the user’s clcarancc lcvcl during the session would rcquirc the prc-filtering to bc rcdone; (3) Changes in the starch domain, (i.e. the sclcction of a diffcrcnt index file corresponding to another large grouping of unstructured data items) would also entail a new prc-filtering operation; and (4) A trusted process may bc rcquircd to perform the prc-filtering (note: trusted proccsscs arc considcrably more costly to design and implement than single-lcvcl proccsscs running in one compartmcnt at a time, under the control of the trusted operating system). The multi-lcvcl indexing architccturc lends itself very well to prc-filtering.

626

of Fig. 2 As it is

for Textual Databases

assumed that files of a similar security label will bc indexed together and that the resulting index file will be at the same label as that of the data f&s, prc-filtering is rcduccd to choosing the index f&s which the originator of the query can bc allowed to set (according to mandatory security). This is a rclativcly simple task which dots not require a trusted process as the trusted operating system can bc relied upon to perform security access control. For example, the pre-filtering process only tries to gain access to the index files of interest; the trusted operating system will indicate to that process if access will bc allowed or denied. The prc-filtering process is thcrcforc informed in a trusted fashion of the index files which can be included in the starch. 2.3.2

Post-filtering

Post-filtering involves the filtering from the query result of all the files for which cqn. (2.8) does not hold, or, in other words, files wjth a security label not dominated by the clearance lcvcl of the originator of the query. Post-filtering implies a trusted process (as the label of the index file may dominate that of the user) and involves the retrieval of the security label associated with each file in the query result. Post-filtering is often prcfcrablc to prcfiltering in situations whcrc the size of the qucty result is much smaller than that of the index file(s) (i.e. when IRI 4 IIndcxl). Post-filtering is usually associated with single-lcvcl indexing architccturc as it is more natural to pcrform post-filtering in systems supporting that architecture. It is intcrcsting to realize that the operations of both the pre-filtering and post-filtering operations have to bc trusted. For the former, the trust is guaranteed by the trusted operating system whcrcas, for the latter, it has to bc built in the filtering process, a far more cxpcnsivc and difficult option. 2.3.3

Remarks

East of security filtering is not the only criterion for sclccting an indexing architecture: one should also consider the file storage architecture. In singlelcvcl indexing architccturc, storage can be arranged

Computers

in any particular fashion which cithcr maximizes performance or minimizes storage requirements. In multi-level indexing architecture, the goals arc the same but there arc further requircmcnts on the structure of the storage. For cxamplc, it is often dcsirablc to cnsurc that files of similar security label are grouped together and arc associated cithcr ’ logically or physically with their index files. Multi-level indexing architectures arc sensitive to the proliferation of individual security compartmcnts. When the number of security compartments in use increases, there is an extra ovcrhcad in index files and the length of time rcquircd for the prc-filtering becomes longer. In systems whcrc there arc a multitude of security compartments with very few files in each compartment, thcrc may be no advantage to adopting the multi-level indcxing architecture.

3. Profiling

Operations

Real world operations arc not static and, similarly, the contents of a textual database arc also expected to change over time. By changing, is meant the arrival ot new intormation rather than the updating of existing information. When new information has arrived, it is logical to assume that users of the system will want to know about it. This can be accomplished in two ways:

and Security,

specific starch patterns is called: Z’rc$llir;~. Thcrc intcrcsting security issues in profiling:

l In a fashion reminiscent of pol$nstantiation of relational database rows [6], prohlcs on similar topic, set by the same user, may bc diffcrcnt, dcpcnding on their security label.

3.1

Profiling

Concepts

Bcforc attempting to invcstigatc profiling opcrat-ions fur&r, some basic definitions arc nccdcd to dcscribc the contents of the textual database as time progrcsscs. In this section, time will bc assumed to bc increasing and snapshots of the system can bc obscrvcd at A intervals. Thcrcforc, progression is starting at time t, the following observed: t, r+A,

r+2A,...

(3.1)

To this progression corresponds the following of the set of files in the textual database:

view

F,. F,+A, F,+2A. . . .

(3.2)

whcrc the following

relation

holds:

new arrivals in the interval

1

(1)

(2) The system could perform scarchcs on ncwl) arrived information using user-specific pro!& (i.e. starch patterns) and, if a search is successful, send a mcssagc to the user with the name of the file which may contain rclcvant information. The first altcrnativc is not very flcxiblc and it is clear that the second is prcfcrablc. Incidentally, the starching of newly arrived material against uscr-

arc

l It is likely that profiles arc scnsitivc and should bc assigned individual security labels; and

F ,+,,A=+,,-l)AU Users could periodically resubmit their qucrics in the hope that newly arrived information gcncrates new hits, that is, new documents which match the starch criteria; or

Vol. 9, No. 7

A} (3.3)

The domain fort: Profiling 3.2

of the profiling

domain

Security

operations

= F, + ,,An F, +(,,_ ,),,

Requirements

is thcrc-

(3.4

on Profiles

Profiles arc set by the users thcmsclvcs. Given a user U with a security clcarancc C(V) (including lcvcl and catcgorics), thcrc exists a set of profiles for that user, cxprcsscd as

627

C. Laferriere et al.lSecurt?y Architectures

whcrc pc, is an individual profile associated with user U. As in the case of qucrics, a profile is composed of words linked through conjunctions, disjunctions ccc., but, in addition, a profile is also charactcrizcd by a security label, cxprcssed as L ( pc ,,). A typical profile can then bc cxprcsscd as PC ,=(QJc,),

WI A W? v . ..).

(3.6)

The prcscncc of L(pc,,) in cqn. (3.6) is very significant; it is a realization that a great deal of information can bc glcancd from a query or profile. It should bc rcalizcd that in the case of a regular query, the security label is implicit to the query operation and is that of the current level of the user making the query. To convince oneself that profiles can be scnsitivc, one should consider the cast of a police analyst wishing to bc kept informed of new documents rclatcd to terrorist activities and tcrrorist organizations. Assuming that the analyst knows of two informers, Mr. X and Ms. Y, and is intcrcstcd to see if their names will appear in conncction with particular terrorist or anizations, the analyst could set the following pro H11~: Profile:

terrorism,terroristgroupA, informer, Mr. X, Ms. Y

In the above context, it is easy to see that anyone browsing through this profile would gain, potcntially, a considcrablc amount of information about two possible informers (with dangerous conscqucnccs from Mr. X’s and Ms. Y’s pcrspcctivc). It thcrcforc follows that profiles have to be charactcrizcd by a security label which indicates their sensitivity. As well, users may have diffcrcnt profiles at diffcrcnt security labels which will be applied to the same documents. This implies that users will have security label specific profiling done on their behalf. 3.3

Profiling

Function

The profiling

function

P can now bc d&cd

as

P:[ Fr+p,a n F,+,,,- ,)A] x J’L.-M:f; x Pi -

628

Ylli

(3.7)

for Textual Databases

whcrc the profllcs arc on a per user basis (as cated by PC) and whcrc M is a set of mcssagcs nq, being a boolean indicating that the starch given file with a given profile was a success failure.

indiwith on a or a

From the previous discussion, it is obvious that profiling uses the same concepts and functions as indexing and starching. The architccturc is diffcrcnt, howcvcr, and has to be carefully dcsigncd to ensure the sccuriry of the profiling operations. 3.4

Profiling

Architecture

suitable for profiling is shown in Fig. 4. In that figure, new f&s (or documents) arc first proccsscd by a trusted document labeler process which is entrusted with determining the proper security label of the documents (according to some prc-dctcrmincd schcmc or method) and to attach labels to the files containing those documents. Altcrnativcly, document loading can occur at a single label, thcrcforc making the labclling implicit. &

architccturc

Following the creation of properly labcllcd files (using scrviccs of the trusted operating system), the following steps would bc carried out, with rcfcrcncc to Fig. 4: Each of the newly created files would bc indcxcd so that starching with various profiles can be done quickly and cffcicntly. The indexing architccturc is of the multi-lcvcl type in the diagram of Fig. -C although it dots not have to be. The architccturc of Fig. 4 is simply one that works. (1)

(2) A starch process is instantiated at the label of each profile (note that profiles with the same security label can bc grouped for starching cfficicncy). The sclcctcd profile bccomcs the query for the starch process and, in the architccturc of Fig. 4, the domain of the starch is rcprcscntcd by all index files with security labels dominated by that of the search process, hence the currently sclcctcd profile. It should be cmphasizcd that the starch domain is composed of new information only, as per cqn. (3.7).

Computers and Security, Vol. 9, No. 7

powerful and useful application level utilities and are of great value to those who USCthem. Whcrcvcr confidentiality of the information in the TDBMS is the system should bc built upon a important, strong and consistent security architecture. This paper presented two such architccturcs, single-lcvcl and multi-lcvcl indexing and also introduced an architecture for the profiling of incoming data. As most of the information in TDBMS is stored in trusted operating system objects, the task of safcguarding that information rests mostly with the operating system. This paper cstablishcd, howcvcr, that, in addition to text files of known sensitivity, other information, such as index files and user profiles, was used by the TDBMS. As the access controls of the operating system can bc relied upon to provide protection to this additional information, its sensitivity should be assessed correctly in order to ensure secure operations.

Fig. 4. Profiling

operation

architecture.

(3) If the search is successful, a message is sent to the user who owns the pro& The message is sent at the security label of the profile. It is assumed that the trusted operating system enforces strict label equality on message passing. The reason for this label equality rcquircmcnt is that the user may have diffcrcnt profiles at diffcrcnt security labels. I

”

A

From a security standpoint, it is obvious that a sound security architecture and a trustworthy operating system (of the TCSEC B lcvcl type) arc necessary. In practical systems, other concerns should not bc forgotten; rctricval pcrformancc, case of USC, congeniality of the user interface, implcmentation of the clicnt/scrvcr model etc., arc all criteria which arc of great importance and which should be taken into account during the design stage.

References The architecture dcpictcd in Fig. 4 is not complete as several other utilities have to bc provided in an operational profiling system. Ncverthclcss, it is consistent from a security standpoint. It provides for secure profiling of newly arrived material according to user-spccificd profiles which may exist at different security labels. 4. Concluding Textual

database

[2]

[3] [4]

[j] [o]

Remarks managcmcnt

[l]

systems

arc

very

Deparmcnt of Defcnsc (DOD) Trusted Computer Sysmn Evaluation Criteria, IIon 5200.28-S771, Dccembcr 1985. National Computer Security Ccnrcr, Trusted Network Interpretation of the Trusted Compurcr Sysrcm Evaluation Criteria, NCSC-7%~005, VERSION I, July 3 I, 1Y87. TOPIC User’s Guide, VERI’I’Y, July, I Y8Y. R_K/7’EX7‘ Rejiwt~c~~Mmun/, Version +.5. FULCRUM, June 1988. S?NRS/CMS I$mratiorr Rctriwal Guide, LljM, SH 12-5366. D. E. Dcnning, T. F. Lunt. II. I<. Schcll. M. Hccktnan and W. Shocklcy, A Multilcvcl Data Model, Pm. IEEESynrp. ON Satrrity and Privacy, April 1987, pp. 220-234.

629

C. Laferriere et aLlSecurity Architectures

Claude Laferriere is a technical architect with SHL Sysretnhouse Inc., a firm specializing in systems integration. He received a B.Sc. with honours in electrical engineering from the University of Axon in Birmingham. Hirmingharn, U.K., an M.A.Sc. in elecrrical engineering from the University of Ottawa, Ottawa, Ontario, Canada, and a Ph.D. in electrical cngincering from Carleton Universiry. Ottawa, Ontario, Canada. His interests are computer communication and database sccurirv. communications protocols. operaring systems and tnathetnahcal sofnvare verification. He is a tnembcr of the Institute of Electrical and Electronics Engineers and the Association of Professional Engineers of thr Province of Ontario.

Owen Higginson is a senior technical architect with 9% Systemhouse Inc., a firtn specializing in sysretns inregrarion. He received a B.A. with honours in economics from Concordia Universiry in Monrrcal, P.Q., Canada. His interests are operating systems, informarion retrieval, distributed sysrcms and programming tools and techniques. He is a member of rhr Associarion for Computing Machinery.

Gordon G. Bell rcccived a B.A. Honours (computer science and music) degree at Queen’s Universiry, Kingston, Canada, tn 1%~. He ts currently a Systems Engineer at SHL Systemhouse inc. where he has worked on numerous projects ranging from postal and air traffic systrml co R secure office network.

630

for Textual Databases