`

`

`

`Publisher: Robert Ipsen
`Editor: Carol A. Long
`Managing Editor: Micheline Frederick
`Text Design & Composition: Interactive Composition Corporation
`
`Designations used by companies to distinguish their products are often claimed as trade(cid:173)
`marks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product names
`appear in initial capital or ALL CAPITAL LETTERS. Readers, however, should contact the ap(cid:173)
`propriate companies for more complete information regarding trademarks and registration.
`
`This book is printed on acid-free paper. i§
`
`Copyright© 2001 by Ross J. Anderson. All rights reserved.
`
`Published by John Wiley & Sons, Inc.
`
`Published simultaneously in Canada.
`
`No part of this publication may be reproduced, stored in a retrieval system or transmitted
`in any form or by any means, electronic, mechanical, photocopying, recording, scanning or
`otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright
`Act, without either the prior written permission of the Publisher, or authorization through
`payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood
`Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for
`permission should be addressed to the Permissions Department, John Wiley & Sons, Inc.,
`605 Third Avenue, New York, NY 10158-0012, (212) 850-6011, fax (212) 850-6008, E-Mail:
`PERMREQ@ WILEY.COM.
`
`This publication is designed to provide accurate and authoritative information in regard to
`the subject matter covered. It is sold with the understanding that the publisher is not engaged
`in professional services. If professional advice or other expert assistance is required, the
`services of a competent professional person should be sought.
`
`Library of Congress Cataloging-in-Publication Data
`Anderson, Ross, 1956-
`Security engineering: a guide to building dependable distributedsystems/RossJ. Anderson.
`p. cm.
`"Wlley Computer Publishing."
`Includes bibliographical references and index.
`ISBN 0-471-38922-6 (pbk.: alk. paper)
`1. Computer security. 2. Electronic data processing-Distributed processing. I. Title.
`QA76.9.A25 A54 2001
`005.8-dc21
`
`00-068486
`
`Printed in the United States of America.
`
`1098765432
`
`DivX, LLC Exhibit 2015
`Page 2015 - 3
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security Engineering: A Guide to Building Dependable Distributed Systems
`
`CH AP TE R
`
`4
`
`Access Control
`
`Going all the way back to early time-sharing systems, we systems people regarded the
`users, and any code they wrote, as the mortal enemies of us and each other. We were like
`the police force in a violent slum.
`—ROGER NEEDHAM
`Microsoft could have incorporated effective security measures as standard, but good
`sense prevailed. Security systems have a nasty habit of backfiring, and there is no doubt
`they would cause enormous problems.
`—RICK MAYBURY
`
`4.1 Introduction
`
`Access control is the traditional center of gravity of computer security. It is where se-
`curity engineering meets computer science. Its function is to control which principals
`(persons, processes, machines, . . .) have access to which resources in the sys-
`tem—which files they can read, which programs they can execute, how they share data
`with other principals, and so on.
`
`NOTE
`This chapter necessarily assumes more computer science background than previous
`chapters, but I try to keep it to a minimum.
`
`51
`
`DivX, LLC Exhibit 2015
`Page 2015 - 4
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Chapter 4: Access Controls
`
`Figure 4.1 Access controls at different levels in a system.
`
`Access control works at a number of levels, as shown in Figure 4.1, and described in
`the following:
`
`1. The access control mechanisms, which the user sees at the application level,
`may express a very rich and complex security policy. A modern online busi-
`ness could assign staff to one of dozens of different roles, each of which could
`initiate some subset of several hundred possible transactions in the system.
`Some of these (such as credit card transactions with customers) might require
`online authorization from a third party while others (such as refunds) might
`require dual control.
`2. The applications may be written on top of middleware, such as a database
`management system or bookkeeping package, which enforces a number of
`protection properties. For example, bookkeeping software may ensure that a
`transaction that debits one ledger for a certain amount must credit another
`ledger for the same amount.
`3. The middleware will use facilities provided by the underlying operating sys-
`tem. As this constructs resources such as files and communications ports from
`lower-level components, it acquires the responsibility for providing ways to
`control access to them.
`4. Finally, the operating system access controls will usually rely on hardware
`features provided by the processor or by associated memory management
`hardware. These control which memory addresses a given process can access.
`
`As we work up from the hardware through the operating system and middleware to
`the application layer, the controls become progressively more complex and less reli-
`able. Most actual computer frauds involve staff accidentally discovering features of the
`application code that they can exploit in an opportunistic way, or just abusing features
`of the application that they were trusted not to. But in this chapter, we will focus on the
`fundamentals: access control at the hardware and operating system level. (Application-
`level controls aren’t different in principle, but I leave detailed discussion to Part 2 of
`this book.)
`As with the other building blocks discussed so far, access control makes sense only
`in the context of a protection goal, typically expressed as a security policy. This puts
`us at a slight disadvantage when discussing PCs running single-user operating systems
`such as DOS and Win95/98, which have no overt security policy: any process can
`modify any data. People do have implicit protection goals, though; you don’t expect a
`
`52
`
`DivX, LLC Exhibit 2015
`Page 2015 - 5
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security Engineering: A Guide to Building Dependable Distributed Systems
`
`shrink-wrap program to trash your hard disk. So an explicit security policy is a good
`idea, especially when products support some features that appear to provide protection,
`such as login IDs.
`I mention one protection technique—sandboxing—later, but leave off a substantial
`discussion of viruses and the like to Section 18.4. In what follows, the focus will be on
`protection mechanisms for systems that support the isolation of multiple processes. I
`discuss operating system mechanisms first, as it is their requirements that usually drive
`hardware protection system design.
`
`4.2 Operating System Access Controls
`
`The access controls provided with an operating system typically authenticate principals
`using some mechanism such as passwords or Kerberos, then mediate their access to
`files, communications ports, and other system resources.
`Their effect can often be modelled by a matrix of access permissions, with columns
`for files and rows for users. We’ll write r for permission to read, w for permission to
`write, x for permission to execute a program, and (–) for no access at all, as shown in
`Figure 4.2.
`In this simplified example, Sam is the system administrator, and has universal access
`(except to the audit trail, which even he should only be able to read). Alice, the man-
`ager, needs to execute the operating system and application, but only through the ap-
`proved interfaces—she mustn’t have the ability to tamper with them. She also needs to
`read and write the data. Bob, the auditor, can read everything.
`
`Figure 4.2 Naive access control matrix.
`
`Figure 4.3 Example access control matrix for bookkeeping.
`
`This is often enough, but in the specific case of a bookkeeping system, it’s not quite
`what we need. We want to ensure that transactions are well formed—that each debit is
`matched by a credit somewhere else—so we would not want Alice to have uninhibited
`write access to the account file. We would also prefer that Sam didn’t have this access;
`so that all write access to the accounting data file was via the accounting program. The
`
`53
`
`DivX, LLC Exhibit 2015
`Page 2015 - 6
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Chapter 4: Access Controls
`
`access permissions might now look like those shown in Figure 4.3. (There is still an
`indirect vulnerability in that Sam could overwrite the accounts program with an unau-
`thorised one of his own devising, but we’ll leave off discussing that till Chapter 9.)
`Another way of expressing a policy of this type would be with access triples of user,
`program, file. In the general case, our concern isn’t with a program as much as a pro-
`tection domain, which is a set of processes or threads that share access to the same re-
`sources (though at any given time they might have different files open or different
`scheduling priorities).
`Access control matrices (whether in two or three dimensions) can be used to imple-
`ment protection mechanisms, as well as just model them. But they do not scale well.
`For instance, a bank with 50,000 staff and 300 applications would have an access con-
`trol matrix of 15 million entries. This is inconveniently large. It might not only impose
`a performance problem but also be vulnerable to administrators’ mistakes. We will
`usually need a more compact way of storing and managing this information. The two
`main ways of doing this are to use groups or roles to manage the privileges of large
`sets of users simultaneously, or to store the access control matrix either by columns
`(access control lists) or rows (capabilities, sometimes known as “tickets”) or certifi-
`cates [662, 804].
`
`4.2.1 Groups and Roles
`
`When we look at large organizations, we usually find that most staff fit into one or
`other of a small number of categories. A bank might have 40 or 50 such categories:
`teller, chief teller, branch accountant, branch manager, and so on. The remainder (such
`as the security manager, and chief foreign exchange dealer,...), who need to have their
`access rights defined individually, may amount to only a few dozen people.
`So we want a small number of predefined groups, or functional roles, to which staff
`can be assigned. Some people use the words group and role interchangeably, and with
`many systems they are; but the more careful definition is that a group is a list of prin-
`cipals, while a role is a fixed set of access permissions that one or more principals may
`assume for a period of time using some defined procedure. The classic example of a
`role is the officer of the watch on a ship. There is exactly one watchkeeper at any one
`time, and there is a formal procedure whereby one officer relieves another when the
`watch changes. In fact, in most military applications, it’s the role that matters rather
`than the individual.
`Groups and roles can be combined. The officers of the watch of all ships currently at
`sea is a group of roles. In banking, the manager of the Cambridge branch might have
`his or her privileges expressed by membership of the group manager and assumption
`of the role acting manager of Cambridge branch. The group manager might express a
`rank in the organization (and perhaps even a salary scale) while the role acting man-
`ager might include an assistant accountant standing in while the manager, deputy man-
`ager, and branch accountant are all sick.
`Whether we need to be careful about this distinction is a matter for the application.
`In a warship, we want even an able seaman to be allowed to stand watch if all the offi-
`cers have been killed. In a bank, we might have a policy that “transfers over $10 mil-
`lion must be approved by two staff, one with the rank of manager and one with the
`rank of assistant accountant.” In the event of sickness, the assistant accountant acting
`as manager would have to get the regional head office to provide the second signature
`on a large transfer.
`
`54
`
`DivX, LLC Exhibit 2015
`Page 2015 - 7
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security Engineering: A Guide to Building Dependable Distributed Systems
`
`Until recently, some support for groups and roles existed but was not very widely
`used. Developers either implemented this kind of functionality in their application
`code, or as custom middleware (in the 1980s, I worked on two bank projects where
`group support was hand-coded as extensions to the mainframe operating system). Re-
`cently, Windows 2000 (Win2K) has been launched with very extensive support for
`groups, while academic researchers have started working on role-based access control
`(RBAC), which I discuss further in Chapter 7. We will have to wait and see whether
`either of these has a major effect on application development practices.
`
`Figure 4.4 Access control list (ACL).
`
`4.2.2 Access Control Lists
`
`Another way of simplifying access rights management is to store the access control
`matrix a column at a time, along with the resource to which the column refers. This is
`called an access control list, or ACL. In the first of the examples, the ACL for file 3
`(the account file) might look as shown in Figure 4.4.
`ACLs have a number of advantages and disadvantages as a means of managing secu-
`rity state. These can be divided into general properties of ACLs and specific properties
`of particular implementations.
`ACLs are widely used in environments where users manage their own file security,
`such as the Unix systems common in universities and science labs. Where access con-
`trol policy is set centrally, they are suited to environments where protection is data-
`oriented; they are less suited where the user population is large and constantly chang-
`ing, or where users want to be able to delegate their authority to run a particular pro-
`gram to another user for some set period of time. ACLs are simple to implement, but
`are not efficient as a means of doing security checking at runtime, as the typical oper-
`ating system knows which user is running a particular program, rather than which files
`it has been authorized to access since it was invoked. The operating system must either
`check the ACL at each file access or keep track of the active access rights in some
`other way.
`Finally, distributing the access rules into ACLs can make it tedious to find all the
`files to which a user has access. Revoking the access of an employee who has just been
`fired, for example, will usually have to be done by cancelling their password or other
`authentication mechanism. It may also be tedious to run systemwide checks, such as
`verifying that no files have been left world-writable. This could involve checking
`ACLs on millions of user files.
`Let’s look at two important examples of ACLs: their implementation in Unix and
`NT.
`
`55
`
`DivX, LLC Exhibit 2015
`Page 2015 - 8
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Chapter 4: Access Controls
`
`4.2.3 Unix Operating System Security
`
`In Unix (and its popular variant Linux), files are not allowed to have arbitrary access
`control lists, but simply rwx attributes for the resource owner, the group, and the world.
`These attributes allow the file to be read, written, and executed. The access control list
`as normally displayed has a flag to show whether the file is a directory; then flags r, w,
`and x for owner, group, and world respectively; it then has the owner’s name and the
`group name. A directory with all flags set would have the ACL:
`drwxrwxrwx Alice Accounts
`In the first example in Figure 4.4, the ACL of file 3 would be:
`-rw-r—–---Alice Accounts
`This records that the file is not a directory; the file owner can read and write it;
`group members can read it but not write it; nongroup members have no access at all;
`the file owner is Alice; and the group is Accounts.
`In Unix, the program that gets control when the machine is booted (the operating
`system kernel) runs as the supervisor, and has unrestricted access to the whole ma-
`chine. All other programs run as users, and have their access mediated by the supervi-
`sor. Access decisions are made on the basis of the userid associated with the program.
`However if this is zero (root), then the access control decision is “yes.” So root can do
`what it likes—access any file, become any user, or whatever. What’s more, there are
`certain things that only root can do, such as starting certain communication processes.
`The root userid is typically made available to the system administrator.
`This means that (with most flavors of Unix) the system administrator can do any-
`thing, so we have difficulty implementing an audit trail as a file that he cannot modify.
`This not only means that, in our example, Sam could tinker with the accounts, and have
`difficulty defending himself if he were falsely accused of tinkering, but that a hacker
`who managed to become the system administrator could remove all evidence of his
`intrusion. A common defense is to send the system log to a printer in a locked room
`or—if the volumes of data are too great—to another machine that is administered by
`somebody else.
`The Berkeley distributions, including FreeBSD, go some way toward fixing the
`problem. Files can be set to be append-only, immutable or undeletable for user, system
`or both. When set by a user at a sufficient security level during the boot process, they
`cannot be overridden or removed later, even by root. Various military variants go to
`even greater trouble to allow separation of duty. However, the simplest and most
`common way to protect logs against root compromise is to keep them on a separate
`server.
`Second, ACLs contain only the names of users, not of programs, so there is no
`straightforward way to implement access triples of (user, program, file). Instead, Unix
`provides an indirect method: the suid and sgid file attributes.
`The owner of a program can mark it as suid. This enables it to run with the privilege
`of its owner rather than the privilege of the user who has invoked it; sgid does the
`same for groups. Thus, in order to achieve the functionality needed by Figure 4.3, we
`could create a user “account-package” to own file 2 (the accounts package), make the
`file suid, and place it in a directory to which Alice has access. This special user could
`then be given the access control attributes we want for the accounts program.
`One way of looking at this is that an access control problem that is naturally mod-
`elled in three dimensions—the triples (user, program, data)—is being implemented
`using two-dimensional mechanisms. These mechanisms are much less intuitive than
`
`56
`
`DivX, LLC Exhibit 2015
`Page 2015 - 9
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security Engineering: A Guide to Building Dependable Distributed Systems
`
`triples, and people make many mistakes implementing them. Programmers are often
`lazy or facing tight deadlines; so they just make the application suid root, and it can do
`anything.
`This practice leads to some rather shocking security holes. The responsibility for
`making access control decisions is moved from the operating system environment to
`the program, and most programmers are insufficiently experienced and careful to check
`everything that they should. In particular, the person invoking a suid root program
`controls its environment and can often manipulate this to cause protection failures.
`Third, ACLs are not very good at expressing changing state. Managing stateful ac-
`cess rules, such as dual control, becomes difficult; one either has to do it at the appli-
`cation level or use suid/sgid again. Also, it’s hard to track the files that a user might
`have open (as you typically want to do when revoking their rights on a system).
`Fourth, the Unix ACL names only one user. Older versions allow a process to hold
`only one group ID at a time and force it to use a privileged program to access other
`groups; newer Unix systems put a process in all groups that the user is in. This is still
`much less expressive than one might like. In theory, the ACL and su mechanisms can
`often be used to achieve the desired effect. In practice, programmers are often too lazy
`to figure out how to do this, and so design their code to require much more privilege
`than it really ought to.
`
`4.2.4 Windows NT
`
`Another important operating system whose protection is largely based on access con-
`trol lists is Windows NT. The current version of NT (version 5, or Win2K) is fairly
`complex, so it’s helpful to trace its antecedents. (This can also be useful if you have to
`help manage upgrades from NT4 to Win2K).
`NT4 protection is very much like Unix, and appears to be inspired by it, so it’s sim-
`pler to describe the main innovations.
`First, rather than just read, write, and execute, there are separate attributes for take
`ownership, change permissions, and delete, which means that more flexible delegation
`can be supported. These attributes apply to groups as well as users, and group permis-
`sions allow you to achieve much the same effect as sgid programs in Unix. Attributes
`are not simply on or off, as in Unix, but have multiple values: you can set Access-
`Denied, AccessAllowed, or SystemAudit. These are parsed in that order. If an Access-
`Denied is encountered in an ACL for the relevant user or group, then no access is
`permitted, regardless of any conflicting AccessAllowed flags.
`A benefit of the richer syntax is that you can arrange matters so that much less than
`full administrator privileges are required for everyday configuration tasks, such as in-
`stalling printers. (This is rarely done, though.)
`Second, users and resources can be partitioned into domains with distinct adminis-
`trators, and trust can be inherited between domains in one direction or both. In a typi-
`cal large company, you might put all the users into a domain administered by the
`personnel department, while resources such as servers and printers could be in resource
`domains under departmental control; individual workstations might even be adminis-
`tered by their users. Things would be arranged so that the departmental resource do-
`mains trust the user domain, but not vice versa—so a corrupt or careless departmental
`administrator couldn’t do much damage outside his or her own domain. The individual
`workstations would in turn trust the department (but not vice versa) so that users could
`perform tasks that require local privilege (installing many software packages requires
`
`57
`
`DivX, LLC Exhibit 2015
`Page 2015 - 10
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Chapter 4: Access Controls
`
`this). Administrators are all-powerful (so you can’t create truly tamper-resistant audit
`trails without using write-once storage devices), but the damage they can do can be
`limited by suitable organization. The data structure used to manage all this, and hide
`the ACL details from the user interface, is called the Registry.
`Problems with designing an NT architecture in very large organizations include
`naming issues (which we’ll explore later), the way domains scale as the number of
`principals increases (badly), and the restriction that a user in another domain can’t be
`an administrator (which can cause complex interactions between local and global
`groups).
`One peculiarity of NT is that everyone is a principal, not a default or an absence of
`control, so remove everyone means just prevent a file being generally accessible. A
`resource can be locked quickly by setting everyone to have no access. This brings us
`naturally to the subject of capabilities.
`
`4.2.5 Capabilities
`
`The next way to manage the access control matrix is to store it by rows. These are
`called capabilities. In the example in Figure 4.2, Bob’s capabilities would be as shown
`in Figure 4.5.
`The strengths and weaknesses of capabilities are more or less the opposite of ACLs.
`Runtime security checking is more efficient, and we can do delegation without much
`difficulty: Bob could create a certificate saying “Here is my capability, and I hereby
`delegate to David the right to read file 4 from 9 A.M. to 1 P.M.; signed Bob.” On the
`other hand, changing a file’s status can suddenly become more tricky, as it can be dif-
`ficult to find out which users have access. This can be tiresome when investigating an
`incident or preparing evidence of a crime.
`There were a number of experimental implementations in the 1970s, which were
`rather like file passwords; users would get hard-to-guess bitstrings for the various read,
`write, and other capabilities to which they were entitled. It was found that such an ar-
`rangement could give very comprehensive protection [804]. It was not untypical to find
`that almost all of an operating system could run in user mode, rather than as supervi-
`sor, so operating system bugs were not security critical. (In fact, many operating sys-
`tem bugs caused security violations, which made debugging the operating system much
`easier.)
`The IBM AS/400 series systems employed capability-based protection, and enjoyed
`some commercial success. Now capabilities are making a comeback in the form of
`public key certificates. We’ll discuss the mechanisms of public key cryptography in
`Chapter 5, and give more concrete details of certificate-based systems, such as
`SSL/TLS, in Section 19.5. For now, think of a public key certificate as a credential
`signed by some authority, which declares that the holder of a certain cryptographic key
`is a certain person, a member of some group, or the holder of some privilege.
`
`Figure 4.5 A capability.
`
`58
`
`DivX, LLC Exhibit 2015
`Page 2015 - 11
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security Engineering: A Guide to Building Dependable Distributed Systems
`
`As an example of where certificate-based capabilities can be useful, consider a hos-
`pital. If we implemented a rule stating “a nurse will have access to all the patients who
`are on her ward, or who have been there in the last 90 days,” naively, each access con-
`trol decision in the patient record system would require several references to adminis-
`trative systems, to find out which nurses and which patients were on which ward,
`when. This means that a failure of the administrative systems can now affect patient
`safety much more directly than was previously the case, which is a clearly bad thing.
`Matters can be much simplified by giving nurses certificates that entitle them to access
`the files associated with their current ward. Such a system is starting to be fielded at
`our university hospital.
`One point to bear in mind is that as public key certificates are often considered to be
`“crypto” rather than “access control,” their implications for access control policies and
`architectures are not always thought through. The lessons that could have been learned
`from the capability systems of the 1970s are generally having to be rediscovered (the
`hard way). In general, the boundary between crypto and access control is a fault line
`where things can easily go wrong. The experts often come from different backgrounds,
`and the products from different suppliers.
`
`4.2.6 Added Features in Windows 2000
`
`A number of systems, from mainframe access control products to research systems,
`have combined ACLs and capabilities in an attempt to get the best of both worlds. But
`the most important application of capabilities is in Win2K.
`Win2K adds capabilities in two ways that can override or complement the ACLs of
`NT4. First, users or groups can be either whitelisted or blacklisted by means of pro-
`files. (Some limited blacklisting was also possible in NT4.) Security policy is set by
`groups rather than for the system as a whole. Groups are intended to be the primary
`method for centralized configuration management and control (group policy overrides
`individual profiles). Group policy can be associated with sites, domains, or organiza-
`tional units, so it can start to tackle some of the real complexity problems with naming.
`Policies can be created using standard tools or by custom-coding (Microsoft has an-
`nounced that group policy data will be exposed in a standard schema). Groups are de-
`fined in the Active Directory, an object-oriented database which organizes users,
`groups, machines, and organizational units within a domain in a hierarchical name-
`space, indexing them so they can searched for on any attribute. There are also finer-
`grained access control lists on individual resources.
`As already mentioned, Win2K uses Kerberos as its main means of authenticating us-
`ers across networks.1 This is encapsulated behind the Security Support Provider Inter-
`face (SSPI), which enables administrators to plug in other authentication services.
`
`
`1In fact, it’s a proprietary variant, with changes to the ticket format, which prevent
`Win2K clients from working with existing Unix Kerberos infrastructures. The documenta-
`tion for the changes is released on condition that it not be used to make compatible imple-
`mentations. Microsoft’s goal is to get everyone to install Win2K Kerberos servers. This has
`caused an outcry in the open systems community [76].
`
`59
`
`DivX, LLC Exhibit 2015
`Page 2015 - 12
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Chapter 4: Access Controls
`
`This brings us to the second way in which capabilities insinuate their way into
`Win2K: in many applications, people are likely to use the public key protocol
`SSL/TLS, which is widely used on the Web, and which is based on public key certifi-
`cates. The management of these certificates can provide another, capability-oriented,
`layer of access control outside the purview of the Active Directory. (I discuss SSL/TLS
`in Section 19.5.)
`There are various backward-compatibility issues. For example, high-security con-
`figurations of Win2K with full cryptographic authentication can’t interwork with NT4
`systems. This is because an active directory can exist alongside the registry of NT4,
`but the registry can’t read it. So the deployment of Win2K’s high-security features in
`large organizations is likely to be delayed until all the important applications have mi-
`grated.
`Win2K provides a richer and more flexible set of access control tools than any sys-
`tem previously sold in mass markets. It does still have design limitations. Implement-
`ing roles whose requirements differ from those of groups could be tricky in some
`applications; SSL certificates are the obvious way to do this, but would require an ex-
`ternal management infrastructure. Second, Windows is still (in most of its incarna-
`tions) a single-user operating system, in the sense that only one person can operate a
`PC at a time. Thus, if I want to run an unprivileged, sacrificial user on my PC for ac-
`cessing untrustworthy Web sites that might contain malicious code, I have to log off
`and log on again, or use other techniques that are so inconvenient that few users will
`bother. So users still do not get the benefit from the operating system’s protection
`properties that they might wish when browsing the Web.
`
`4.2.7 Granularity
`
`A practical problem with all current flavors of access control system is granularity. As
`the operating system works with files, this will usually be the smallest object with
`which its access control mechanisms can deal. So it will be application-level mecha-
`nisms that, for example, ensure that a bank customer at a cash machine can see his or
`her own balance but not anybody else’s.
`But it goes deeper than that. Many applications are built using database tools that
`give rise to some problems that are much the same whether running DB2 on MVS or
`Oracle on Unix. All the application data is bundled together in one file, and the oper-
`ating system must either grant or deny a user access to the lot. So, if you developed
`your branch accounting system under a database product, then you’ll probably have to
`manage one access mechanism at the operating system level and another at the data-
`base or application level. Many real problems result. For example, the administration
`of the operating system and the database system may be performed by different de-
`partments, which do not talk to each other; and often user pressure drives IT depart-
`ments to put in crude hacks that make the various access control systems seem to work
`as one, but that open up serious holes.
`Another granularity problem is single sign-on. Despite the best efforts of computer
`managers, most large companies accumulate systems of many different architectures,
`so users get more and more logons to different systems; consequently, the cost of ad-
`ministering them escalates. Many organizations want to give each employee a single
`logon to all the