| Previous | Table of Contents | Next |
For the operating system and applications delivered with it, the network security entities of interest are as follows:
Network adapters are also part of network security because ultimately, network traffic must be marked for a specific physical address. However, these entities are treated as devices on the system itself and fall under the jurisdiction of the access control rules for files and directories.
You are already familiar with I&A for users and groups on stand-alone systems. In networked environments, the only additional concern is the scope of the definitions for these entities in the network. A stand-alone computer contains local repositories for identifying users and groups. Multiple independent stand-alone systems each control their own repositories of user and group information. The namespaces that define users and groups across systems can be disjointed or intersecting. Indeed, the namespaces that define any entities in a network can intersect or remain disjointed depending on how the site is configured.
In Chapter 2, “The Role of Identification and Authentication in Your Environment,” you saw how a group of related nodes could share a single namespace for user and group information. Possible solutions included a central authentication server for many nodes based on NIS, Kerberos, or DCE. Hybrid configurations that permit local user definitions and definitions in a central server must define a precedence relation that claims whether the local repository or the global repository is searched first. NIS and NIS+ provide a configuration file for this purpose. Using local and global repositories for user definitions is tricky because knowing precisely who the user is greatly affects what access rights a user has when connected to a system. Also, intrusion detection tools that try to assign accountability for actions across network nodes need to know the originator of a request.
Most operating systems permit complicated definitions, such as the same username with different UIDs—one on the local node and one in the central authentication server. When systems are configured this way, you must understand who (which UID) the system will reference when making access control decisions. Familiarize yourself with your system’s documentation to understand how the user’s identity is chosen at login time. NT generates a user’s SID that does not have the same value as any user on another node. UNIX UIDs can be identical for different users on multiple nodes.
Higher layer protocols such as NFS assume a common namespace across systems. NFS also provides some basic security features such as transforming the root UID (zero) to that of nobody (–2) when root is accessing files across systems. The UIDs and GIDs stored in the usual operating system repositories, local or remote, are utilized by NFS as the basis for access control decisions. Not all network traffic passes information about users and groups as part of the protocol data. The mail protocol Simple Mail Transfer Protocol (SMTP) knows about network addresses only when it is forwarding mail from one system to another. The mail recipient’s UID and GID are not passed in the mail message itself. Instead, the username is extracted from the header by the mail server. The username is used to decide in which mail spool file to deposit the incoming message. As the mail is forwarded across systems, only the network address is important.
Many other network protocols exchange information between network nodes and do not require user or group information in the protocol. Examples include routing and gateway information protocols or low-level network messages that test whether a node is alive.
To summarize, users and groups are identified and authenticated in network security using one of the following techniques:
Also, when your identity has been verified, the network communication sessions need to pass your credentials around so that operations you request on remote systems can be evaluated according to that system’s access control rules. When you want to run a command remotely on another system, at least one network message sent from your system to the remote node needs to carry your credentials. Otherwise, how would the remote system know how to run the operation securely on your behalf? The remote system will need to create a process context, just as a local login session does, to properly enforce the security policy.
If a user’s access request is to an application object, then the access control rules are evaluated in the context of that application and not by the operating system. In other words, a Database Management System (DBMS) client-server access-control decision is (typically) based on the identity of the user, not on the identity of the computer on which the user is working.
It’s always amusing to remember, though, that the Notes clients, servers, and database files all exist as objects in the operating system, too. The Notes server is a process or thread running in the context of the operating system on which it is installed. The executable program that is the Notes server is stored on disk as an operating system file. Although the Notes server makes its own security relevant decisions about entities that it regulates, the server also has an operating system context, complete with UIDs and GIDs. This dual nature of independent reference monitors on systems is always interesting to think about because it shows how multiple security models can exist concurrently on a system and how a product that implements its own security model can be viewed as a subject or object within the context of a completely different reference monitor and security model. For the systems’ administrator, these environments can be confusing and difficult to secure because so many entities and security mechanisms are crossing boundaries.
| Previous | Table of Contents | Next |