3 — Security Integration Architecture

[Previous] [Next] [Contents] [Index]

3.1 Overview of SIA

The Security Integration Architecture (SIA) is a framework that supports multiple security mechanisms on Tru64 UNIX. All configured security mechanisms that run on the Tru64 UNIX operating system run under the SIA. The SIA allows you to layer various local and distributed security mechanisms onto Tru64 UNIX with no modification to either the security-sensitive commands (such as login, su, and passwd), or the application programming interface (API) routines that obtain password or group entries, particularly getpwnam and getgrgid.

The Tru64 UNIX operating system provides two local security mechanisms: Berkeley Standard Distribution (BSD) security and C2 class security. The default Tru64 UNIX configuration has BSD security enabled.

DCE Security, provided by OSF DCE, is a distributed network security service based on secret-key technology. It provides secure communications (authentication and data protection) and controlled access to resources (authorization) in the distributed environment. Within a DCE cell, DCE registry databases on the Security server nodes (where the Security server daemons, secd, run) contain information about principals, groups, organizations, accounts, and so forth. The local system administrator can create a DCE password override file, /opt/dcelocal/etc/passwd_override, to exclude people from using the local machine, to establish a local root password, or to tailor the local user environments.

3.2 Benefits of SIA

The local system administrator can configure DCE security to use the local SIA facility. Doing so permits users to establish a local terminal session and DCE credentials with a single login command and password.

Enabling DCE SIA also integrates DCE security with the local security mechanism. In addition, Tru64 UNIX account-related functions (such as getpwent) can display information from both the local and DCE registries.

DCE SIA allows you to use the DCE registry as the sole repository for all user accounts. This makes account maintenance easier because there is one central DCE registry to manage. This means that you can log in to any DCE client system if you have a DCE account, even if you do not have a local account on that system.

When a DCE system is initially configured with SIA support, you may want to use the passwd_import utility to migrate local accounts to the DCE registry. Account information stored on a local system in /etc/passwd and /etc/group can selectively be merged into the DCE registry. The passwd_import command with the check option, -c, displays a listing of the differences between the local registry and the DCE registry. After the command is executed, the system administrator can decide what data to merge. Having run passwd_import to create a brand new account in the DCE registry, you must then modify the account with rgy_edit to assign a password and then enable the account for DCE logins. Refer to the OSF DCE Administration Guide — Core Components for more information on passwd_import.

3.3 Using SIA

The local security mechanism for Tru64 UNIX always uses SIA. The system administrator can select DCE SIA when the machine is configured in a DCE cell. The dcesetup utility asks the administrator whether DCE SIA should be enabled. The default response is to enable SIA. See the Gradient DCE for Tru64 UNIX Installation and Configuration Guide for further instructions. Once you have configured a machine in a DCE cell, you can run dcesetup at any time to enable or disable DCE SIA.

When dcesetup enables DCE SIA, it modifies a system SIA configuration file, /etc/sia/matrix.conf. File matrix.conf is a function dispatch table used by all Tru64 UNIX security-related commands (such as login and su). Security commands call subcommands, which are in turn dispatched to one or more security mechanisms that appear in the table. Users should not modify matrix.conf, which is a text file, unless they need to implement a highly specialized security mechanism.

When you enable or disable SIA using dcesetup, you should reboot your machine. This ensures that account attribute inconsistencies are not introduced into system daemons and applications running at the time this DCE modification takes place.

When SIA is enabled and one or more servers in the cell are reconfigured, the client systems must also be reconfigured. Otherwise, DCE services cannot operate.

3.4 Using the SIA Configuration Program

The SIACFG configuration program helps system administrators to manage their SIA environments. Administrators can use SIACFG to display and resolve inconsistencies between UNIX account information stored in the DCE/Kerberos user database and corresponding information stored in the user database of the local machine.

SIACFG aids administrators in an environment where DCE SIA has been selected to control system logon based on shared/network user configuration data (that is, passwords, uids, group memberships, and gids), and where the administrator may not have the option of discarding an existing local user account database, replete with its own uid assignments, group memberships, etc.

The basic function of SIACFG is to compare each account and group defined in the local user database to determine if an entity with the same name and type exists in the DCE registry. If a match is found, a more detailed comparison is performed to determine if there are any inconsistencies (for example, same name but different uids, or same name but different membership lists) between the corresponding entities.

When an inconsistency is detected, SIACFG provides the administrator with an opportunity to resolve the conflict by designing an override entry. (See passwd_override(5sec) in OSF DCE Command Reference for a description of overrides and their format.)

When a local account or group has no analogous entity in the registry, the administrator will be asked to choose whether the account or group should have local-only or cell-wide/public significance. If local-only is chosen, SIACFG will add an override entry to the plan. When published, the plan will insure that the local entity remains distinct from any equivalently named and typed entity that might be added to the DCE registry. If the administrator chooses cell-wide, SIACFG will add directions to the plan to create a corresponding entity in the DCE registry.

For information on activating SIACFG, see the Gradient DCE for Tru64 UNIX Installation and Configuration Guide.

3.5 How DCE Security Affects the Security-Sensitive Commands and Routines

Enabling DCE SIA affects three areas of security:

• Login-related commands
  
• Registry information change commands
  
• Registry information inquiry routines
  

The following sections discuss these commands and routines.

A log file (/opt/dcelocal/var/adm/security/sialog) briefly logs the history of executing DCE SIA routines and the configured security mechanisms. You can use this file for troubleshooting or diagnosing security-related problems. You should clean up this file occasionally.

3.5.1 Login-Related Commands

SIA isolates the security-sensitive commands (login, su, ftp, xdm, lock, dxsession, telnet, rtools, and dtools) from the specific security mechanisms which eliminates the need to modify them for each new security mechanism. When DCE SIA is enabled in the matrix.conf file, SIA invokes DCE routines in response to these commands, to authenticate the login session. The following sections explain the login and the su commands in more detail. The other commands are similar to the login command.

3.5.1.1 login Command

When DCE SIA is enabled, using the login command to start a session invokes both the local security mechanism and DCE. If the login command accepts the password you enter, you have DCE credentials and are also logged in to the local security system.

NOTE: You may be logged in to the local security system even if you have no account on the local system, or if you supplied a valid DCE password that is not your local password.

If you have identical account names in both the local BSD registry and the DCE registry, account attributes in the DCE registry override those in the local registry. In other words, DCE account attributes supersede attributes in /etc/passwd and /etc/group.

If, during login, DCE security rejects your password, the local security mechanism still attempts to validate the login. If your name is in the local account database and your password is valid, you are logged in to the local system, but without DCE credentials; otherwise, the login attempt fails.

Once you have successfully logged in to DCE, a shell variable called KRB5CCNAME is created to point to the current session's login context and ticket cache. This variable points to a filename, such as the following:

/opt/dcelocal/var/security/creds/dcecred_68b91c00

Help prevent misuse of credentials by requiring users to remove their credentials (by running kdestroy) before terminating their login sessions. If your login shell is csh, you can insert the following lines as part of your logout profile:

if (\Qprintenv KRB5CCNAME\Q != "") then
echo "Removing login context and ticket cache..."
kdestroy
endif

If you run ksh, you can add the following line to your .profile:

trap 'echo Removing login context and ticket cache; kdestroy' EXIT

DCE does not support a superuser in its environment. When you issue an su command on a Tru64 UNIX system with DCE turned on, four results are possible. Table 3-1 summarizes these combinations

NOTE: User1 and user2 are nonprivileged accounts.

Table 3-1: User Combinations

Combination	Current UID	New UID
1	user1	user2
2	user1	root
3	root	user2
4	root	root

The following paragraphs discuss each combination.

Combination 1: User1 to User2

You are currently user1 and may or may not have DCE credentials. You issue an su user2 command and are prompted for a password. The username user2 and the password are presented to DCE Security. If they pass the security check, you get a new process with UID and DCE credentials of user2. If they do not pass the DCE security check (see Section 3.5.1 on page 37), the username and password are presented to BSD security. If they pass the BSD security check, the new process has user2's UID but does not have DCE credentials. If they do not pass the BSD security check, the su command fails.

Combination 2: User1 to Root

You are currently user1 and may or may not have DCE credentials. You issue an su or su root command and are prompted for a password. The username root and the password are presented to DCE Security. Because the passwd-override file overrides the root account, you are not allowed to log in to DCE root. However, you get the principal credentials of the local host machine (/.:/hosts/<hostname>/self) after you pass the BSD security check for the root account.

Combination 3: Root to User2

If you only use BSD security, no password is required because root has the power to become anyone. This transformation is not possible in a DCE environment, because root (on this system) does not have any special privileges and cannot be permitted to become any principal in the cell. In this case, you are currently root and may or may not have DCE credentials. You issue an su user2 command and are prompted with the following message:

(DCE) Enter DCE password to obtain DCE credentials,
(DCE) or press return for none.
Password:

The username user2 and password are presented to DCE Security. If they pass the DCE security check, you get a new process with the UID and DCE credentials of user2. If they do not pass the DCE security check, or if you press <Return> at the prompt, the username user2 and password are presented to BSD security. Because you are root, they will pass the BSD security check and the new process has user2's UID but does not have DCE credentials.

Combination 4: Root to Root

In this case, you are also prompted for a password, as in case 3. The username root and the password are presented to DCE Security. Because the passwd-override file overrides the root account, you are not allowed to log in to DCE root. However, because you are root, you pass the BSD security check, and the new process has a UID of zero and DCE credentials for the local host machine principal (/.:/hosts/<hostname>/self).

3.5.2 Registry Information Change Commands

The registry information change commands — passwd (change password), chsh (change shell), and chfn (change finger information) — change information in one of the configured security mechanism's registries. These commands invoke SIA routines, which prompt for a choice of the configured security mechanisms. In the following example, DCE SIA and BSD security are enabled.

You are registered with the following security mechanisms

1   DCE
2   BSD

Select ONE item by number:

If you choose option 1 (DCE), SIA displays the following message:

You have selected:
DCE

SIA then invokes DCE routines that allow you to make changes in the passwd_override file, if your requested information exists, or in the DCE registry. The system displays the following message:

You can change information in passwd_override or DCE registry

1  passwd_override file
2  DCE registry

Select ONE item by number:

The rest of the dialog is similar to the BSD dialog. When DCE SIA is enabled, there is no practical reason to maintain identical passwords in both the local and DCE security registries. A login succeeds when a valid DCE account and password are presented if the host remains configured as a DCE client and the DCE security service is available. In any event, presenting a valid local password always results in a successful local login.

The commands passwd, chsh, and chfn provide most functions of the OSF DCE utility chpass, a platform-dependent tool intended as a reference implementation from OSF. This product does not provide chpass.

The commands adduser, removeuser, and vipw do not affect the DCE registry regardless of whether DCE SIA is enabled.

Refer to the passwd_override(5sec) reference page in the OSF DCE Command Reference for details of the passwd_override command.

3.5.3 Registry Information Inquiry Routines

There are ten registry information inquiry routines:

• getpwent
  
• getpwuid
  
• getpwnam
  
• setpwent
  
• endpwent
  
• getgrent
  
• getgrgid
  
• getgrnam
  
• setgrent
  
• endgrent
  

These API calls also include their reentrant routines, if they exist. For these registry information inquiry routines, SIA invokes the configured security mechanism routines in the order in which they are placed in the SIA configuration file (matrix.conf file) until it finds the needed information. If none of the configured mechanisms fulfills the request, the get call fails. For example, the following line exists in the matrix.conf file:

siad_getgrnam=(DCE,/usr/shlib/libdcesiad.so), (BSD, libc.so)

The getgrnam (get a group entry by its name) call first calls the DCE siad_getgrnam routine to try to extract the requested information from either the passwd_override file, if it exists, or the DCE registry. If it succeeds, the getgrnam call returns the DCE information in its return group structure. If DCE fails, it continues to call the BSD siad_getgrnam routine to get the needed information. If it succeeds, the getgrnam routine returns the BSD information in its return group structure. If the getgrnam routine does not find the requested information in either DCE or BSD, it returns a failure; that is, a NULL pointer.

Operations that depend on registry information can behave more reliably when you maintain consistency between names that exist in both the local registry and the DCE registry. For instance, if a user account is registered in /etc/passwd and DCE, consistent password information, default shell, and similar information lets users log in using the same password even if the DCE registry is not available.

Consistency between group names in the local registry and the DCE registry is also desirable. The initial DCE cell configuration procedure declares several standard UNIX group names (such as system, bin, and kmem) in the DCE registry.

Because DCE SIA has precedence in the SIA matrix, a call to getgrnam( ) for the bin group extracts the group attribute record from DCE rather than /etc/group. This has a subtle effect on such programs as newgrp, which call getgrpnam( ) implicitly. In the example % newgrp bin, the membership list for the bin group is consulted to determine if the primary group of the caller can be set to bin. However, newgrp will simply fail if membership in the bin group is denied in the DCE bin record, even though it is granted in /etc/group.

NOTE: The su command does not call getgrnam( ) to determine membership in the system group. Therefore users can be granted privilege to su root simply by adding them to the system record in /etc/group. Also, note that the attribute values of three groups (system, bin, and kmem) are further qualified by their presence, by default, in the group_override file. See Section 3.9.2 on page 47 for more information.

UNIX account functions such as finger and getpwent also get their attribute data from the DCE registry. Consequently, attributes such as default directory and shell must be properly maintained in the local and DCE registries. Any unintentional inconsistencies between the two registries can be troublesome. Administrators must also be careful not to inadvertently break a local account by creating an identical account name in the DCE registry for another user elsewhere on the network.

3.6 Using DCE SIA With the Tru64 UNIX Enhanced Security Option

This section explains special considerations for using the DCE SIA feature with the Tru64 UNIX Enhanced Security option.

The Tru64 UNIX Enhanced Security option, also known as C2 security, is the stricter of two security mechanisms supplied with Tru64 UNIX. The other, BSD, is supplied with the base operating system and is enabled by default. Enhanced Security is offered as an optional product, and is documented in the Tru64 UNIX Security Manual.

Enhanced Security derives much of its value from a more conservative approach toward security management. When DCE uses Enhanced Security via SIA, it operates under restrictions that affect ease of use for the DCE user and administrator. This added inconvenience is the price of a more secure system.

DCE SIA under Enhanced Security is best described by a comparison with BSD security. Table 3-2 compares the relative SIA advantages available when the underlying security mechanism is Enhanced Security or BSD security.

Table 3-2: Benefits of Using SIA with BSD Security or Enhanced Security

SIA BSD Security	SIA Enhanced Security (C2) Option
BSD security enabled	Strict C2 security enabled
Integrated login	Integrated login (password consistency must be maintained between local and remote (DCE) registries).
Local and remote registries synchronized with passwd_export	Manual synchronization of local and remote (DCE) registry required. (the passwd_export utility is not currently available.)
Local login even without an account in the local registry	Local login requires an account in the local registry

DCE SIA offers several advantages which differ somewhat depending on whether the underlying security mechanism is BSD security or Enhanced Security.

• Integrated login gives a user both the local login context and the DCE network credentials simultaneously when performing a UNIX login. When the underlying security mechanism is Enhanced Security, additional administrative action is usually necessary to enable integrated login. This action will be described shortly.

• A local login to participating hosts.

While SIA offers both of these advantages with either BSD security or Enhanced Security, there are some administrative differences:

• With DCE SIA and BSD security, user account information can reside solely in the DCE Security Service registry. Account information need not be maintained in a host's local registry. This provides a significant administrative advantage as all accounts can be maintained in one convenient location rather than on separate hosts with separate login requirements. Integrated login and local login work because the local DCE SIA mechanism overrides the local registry.

• The BSD security mechanism allows the use of the passwd_export and passwd_import utilities to move account information between the local registry and the DCE registry. If account information is also maintained in the local registry, consistent passwords, UIDs, GIDs, and so on must be maintained in both the local and DCE registries.

• With DCE SIA and enhanced security, consistent user account information must be maintained in both the DCE Security Service registry and the host's local registry. Section 3.5.3 on page 41 described the need for consistent information for routines that rely on DCE registry information. Similarly, consistent passwords must be maintained between the DCE registry and the local registry or integrated login will fail.

• The current version of the Enhanced Security mechanism does not support the use of the passwd_export or passwd_import utilities and so account information must be manually copied between DCE and participating hosts.

As with DCE SIA and BSD security, SIA does not provide an all-encompassing change password mechanism for SIA. But with Enhanced Security, the local login mechanism must succeed, so if passwords are inconsistent, integrated login is not achieved. When users run the passwd utility to change their passwords, the system prompts the user to select one or the other registry mechanism. The user must run passwd twice, to change the password in both places. If passwords are inconsistent, the user may use the local password to log in.

3.7 Performance Considerations for DCE SIA

DCE SIA is a convenience feature that greatly simplifies account administration and the acquisition of DCE credentials. However, its impact on the performance of some UNIX security functions is worth noting in certain cell and host configurations. In general, performance is constrained by a characteristic of DCE SIA-enabled systems: whenever a BSD security function is called, transparent DCE registry lookups can occur. Non-DCE applications that run on the host can perform DCE registry lookups unawares, with the result that certain functions (getpwent( ) and getgrent( ) in particular) may take noticeably longer.

3.7.1 Performance of getpwent( ) and getgrent( ) Functions

DCE SIA affects the speed of the getpwent( ) and getgrent( ) functions. When DCE SIA is not enabled, these operations result in a simple lookup in the /etc/passwd and /etc/group files. When DCE SIA is enabled, each invocation of these routines results in at least three process context switches, a bind operation to a registry (that may be remote), and a registry lookup. If performance is critical, an application or UNIX utility may need to be modified to get this data directly from the UNIX files, unless DCE registry data is specifically sought.

3.7.2 The Impact of DCE SIA on Login Performance

The UNIX login function, which is virtually instantaneous without DCE SIA, now takes from between 2 to 5 seconds. This delay affects logins to all accounts on a DCE SIA enabled host, even those that do not use the DCE registry. In most cases, users will not care because the login is a single operation performed once or twice a day.

However, some server applications, such as ftp, perform a system login as a matter of course and for every client connect. If a server application performs many hundreds of logins an hour, the performance of the application and the system itself may degrade noticeably.

DCE SIA is not recommended on hosts where applications make extremely heavy use of system login and registry query operations (such as getpwent( ) and getgrent( )). When administrators want such applications to use the DCE registry, they can copy the DCE account and group data to the local system registry by using the DCE passwd_export utility. The applications can then get the DCE data from the local registry.

3.7.3 UID Management

When you create a DCE cell, you are responsible for managing the UIDs for that cell. Having incompatible UIDs between the DCE registry and the local password file is not a problem until either DCE DFS is available or DCE SIA is enabled. The initial cell creation does not use UIDs that are already in use on the local system. For its default accounts, DCE SIA uses UIDs 30 to 35 if they are available. Other DCE implementations may use accounts in the range of 100 to 105. After cell creation, subsequent accounts in the DCE registry use the next available UID. The minimum UID value used is controlled by the rgy_edit command.

3.7.4 Executables in /sbin

The executables in the /sbin directory are statically linked. When DCE SIA is enabled, executables such as /sbin/ls may not properly translate UIDs and GIDs. To avoid this problem, use the executables in the /bin directory, which are dynamically linked with the libc.so shareable image. You can do this by putting /bin before /sbin in your PATH environment variable.

NOTE: The root account has /sbin its PATH by default.

3.7.5 rlogin

During rlogin to a host with DCE SIA enabled, if the incoming account has an entry in the .rhosts file of the target account, no DCE credentials are obtained and a warning message is displayed.

If the user's home directory is specified in the DFS namespace, access to that directory may be denied.

3.7.6 Changing root Password

If you change a machine's root password, you should run the passwd command twice, first to change it in the BSD location, /etc/passwd, then to change it in the DCE registry location, /opt/dcelocal/etc/passwd_override. If you change it in /etc/passwd but not passwd_override, you will see a DCE informational message, when you attempt to enter the su command, that says "Unable to validate/certify identify". If you change it only in passwd_override, the new password does not take effect.

3.7.7 Credentials Obtained for Intercell Login are Poorly Protected

When a user logs in as a principal of a foreign cell to a machine running DCE SIA (or any other integrated login system that performs a local system login on behalf of a DCE user), his or her UID identity on that machine is that of the Kerberos cross cell proxy principal created for the foreign cell. If multiple users log in to the same machine from the same cell, the local credential files created for each are owned by the same UID. As a result, users from the same cell can tamper with or borrow the credentials of others. Because exclusive control of one's credential files is an important part of DCE security, this behavior may be unacceptable for some customers running multicell environments who have strict security requirements.

NOTE: This problem does not affect the trustworthiness of intercell credentials, only those obtained during integrated login where other users from the same cell are not trusted. Administrators can disable intercell login from a foreign cell by setting the valid flag of the foreign cell principal to be not valid for login.

3.8 Performance Considerations for Registry Replication

Registry replication is a method of achieving robustness and redundancy in DCE cells. If one registry becomes unavailable, users or applications can rely on other replicas for security information. Unfortunately, replication does not always improve response, as DCE presently has no intelligent algorithm for selecting the fastest replica to bind to.

During login, the DCE runtime may choose to bind to a replica in another LAN (in the case of a multi-LAN cell), or time out waiting to connect to a replica that is not operational. With DCE SIA enabled, this behavior may present unacceptable delays in such routine UNIX shell commands as % ls -l.

You might consider the following guidelines and suggestions as ways to minimize replication-related latencies:

• You must actively monitor and maintain the availability of all replicas in the cell. A sound strategy is to have two hosts per LAN that serve as dedicated security replica servers, and to have a process that constantly monitors the replicas to sense their availability. Because some registry operations will bind first to a read-only replica, a multi-LAN cell should have at least one additional read-only replica on the LAN that has the master replica.

• If the cell spans LANs, be aware of latencies that may be introduced if a user in one LAN attempts to bind to and operate on a replica in another LAN. You can avoid the CDS overhead of binding to a replica, and offer a specific list of candidate replicas by inserting bindings in the pe_site file. This technique requires administrative attentiveness and is not generally recommended, but may be useful in some situations. Normally the pe_site file is used only during configuration time, to facilitate access to a registry server without reliance on CDS. It contains a hard coded list of registry bindings, one being selected randomly during a site bind. Use of this file is activated by setting the BIND_PE_SITE environment variable, and the effect is only for the process in which the variable is declared. A pe_site file is created when a host is configured, and placed in /opt/dcelocal/etc/security.

• Should you choose to define the BIND_PE_SITE environment variable, as a regular DCE management strategy, you should monitor the status of servers listed in the pe_site file. If a client goes to the pe_site file and is unable to bind successfully, the client will simply fail to bind. There is no fall-through to other registry servers that may be available.

This section describes how to use the group_override file and its effect on local data.

3.9.1 Use of /opt/dcelocal/etc/group_override

Whenever a DCE host is initially configured, a group_override file is created automatically in the /opt/dcelocal/etc directory. This file contains override GIDs for the bin and kmem groups. Its purpose is to correct GID inconsistencies between /etc/group on Tru64 UNIX systems and the registry for these standard UNIX-style group names. Without this adjustment, a host running DCE SIA reports incorrect group names for these standard group UIDs with the ls\ -l command and produces other undesirable effects.

3.9.2 Effect of Local Override on Group Data

The new group override feature may affect local system routines, such as groups and ls, that use group name attributes. The local group_override file may override membership and GID attributes for group names stored in the registry. System routines such as chgrp, which confer access rights based on group membership, assign rights according to the following rule:

A user is given membership in a group in one of three ways:

• When granted in /etc/group and the group name does not appear in the registry

• When granted on the group's member list in the registry and no explicit group_override file entry exits to prevent it

• When a group override entry for a given group lists the user as a member

The following books provide more information about SIA and managing security registries:

• DIGITAL UNIX Guide to System Administration. This book provides a detailed explanation of SIA.

• OSF DCE Administration Guide — Core Components. The DCE Security Service part provides information on performing routine maintenance and importing UNIX accounts to DCE.

• OSF DCE Command Reference. This book contains reference pages for passwd_import(8sec), passwd_export(8sec), and passwd_override(5sec).

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Copyright © 2001 Entegrity Solutions Corporation & its subsidiaries.

Copyright © 1998-2001 Compaq Computer Corporation.

All rights reserved.