Page 400 - DCAP103_Principle of operating system

Unit 13: Input/Output and Security of Windows

13.3.3 Implementation of Security Notes
Security in a standalone Windows 2000 system is implemented by a number of components, most
of which we have already seen (networking is a whole other story and beyond the scope
of this site). Logging in is handled bywinlogon and authentication is handled by lsass and
msgina.dll. The result of a successful login is a new shell with its associated access token. This
process uses the SECURITY and SAM keys in the registry. The former sets the general security
policy and the latter contains the security information for the individual users.
Once a user is logged in, security operations happen when an object is opened for access.
Every OpenXXX call requires the name of the object being opened and the set of rights needed.
During processing of the open, the security manager checks to see if the caller has all the rights
required. It performs this check by looking at the caller’s access token and the DACL associated
with the object it goes down the list of entries in the ACL in order. As soon as it finds an entry
that matches the caller’s SID or one of the caller’s groups, the access found there is taken as
definitive. If all the rights of the caller needs are available, the open succeeds; otherwise it fails.
DACLs can have Deny entries as well as Allow entries, as we have seen. For this reason, it is
usual to put entries denying access ahead of entries granting access in the ACL, so that a user
who is specifically denied access cannot get in via a back door by being a member of a group
that has legitimate access.
After an object has been opened, a handle to it is returned to the caller. On subsequent calls, the
only check that is made is whether the operation now being tried was in the set of operations
requested at open time, to prevent a caller from opening a file for reading and then trying to
write on it. Any log entries required by the SACL are made.

13.4 Caching in Windows 2000

The Windows 2000 cache manager does caching for performance reasons, conceptually similar
to caches in other operating systems. However, its design has some unusual properties that are
worth looking at briefly.
The cache manager’s job is to keep file system blocks that have been used recently in memory
to reduce access time on any subsequent reference. Windows 2000 has a single integrated cache
that works for all the file systems in use, including NTFS, FAT-32, FAT-16, and even CD-ROM
file systems. This means that the file systems do not need to maintain their own caches.
As a consequence of the design goal to have a single integrated cache despite the presence of
multiple file systems, the cache manager is located in an unusual position in the system.
It is not a part of the file system because there are multiple independent file systems that may
have nothing in common. Instead it operates at a higher level than the file systems, which are
technically drivers under control of the I/O manager.
The Windows 2000 cache is organized by the virtual block, not by the physical block. The
traditional file caches keep track of blocks by two-part addresses of the form (partition, block),
where the first member denotes a device and partition and the second member is a block number
within that partition. The Windows 2000 cache manager does not do that. Instead, it uses (file,
offset) to refer to a block. The reason for this unorthodox arrangement is that when a request
comes in to the cache manager, it is specified as (file, offset) because that is all the calling process
knows. If cache blocks had been labeled by a (partition, block) tag, the cache manager would
have no way of knowing which (file, offset) block corresponds to which (partition, block) block
since it is the file systems that maintain those mappings.

LOVELY PROFESSIONAL UNIVERSITY 393