| Sun Mainframe Transaction Processing Software Administrator's Guide |    
|
| Sun Mainframe Transaction Processing Software Administrator's Guide |
|
| C H A P T E R 7 |
|
Security |
Sun MTP security, which integrates built-in security features and operating environment security mechanisms, ensures a secure environment from the time a user logs on and executes a transaction until the user logs off.
This chapter includes the following topics:
This section explains basic UNIX security concepts and mechanisms found in every UNIX implementation. Your operating environment might have more sophisticated security features that you can use to secure your application environment. The definitive source for all UNIX security and system administration information is the documentation that shipped with your system.
Every UNIX system has a single user that has unrestricted access to all parts of the system. This user is called the superuser and the user name is root. You can use either term, superuser or root, to refer to this user. The UNIX system administrator should be the only person that has access to the root password.
UNIX security is based on the concept of a user. Every user must have an assigned user name. The system administrator is responsible for assigning a unique user name to each user.
A user must log in to a UNIX system. The login process has two steps. First, the user must type a user name, then a password. The password is not displayed on the monitor.
User names, passwords, and other account information, are maintained in the password database. On most systems, the system administrator uses an administrative tool to manage the password database instead of editing the file with a text editor. The password database is usually stored in the /etc/password file, which contains an entry for each user. An entry consists of a colon-separated list of fields. The common format is:
|
User's unique login name. Login names are normally eight characters or less. |
|
|
User's password. The system administrator should set the password with the passwd command. The superuser can change any user's password; users can only change their own with the passwd command. |
|
|
Numerical identifier for the user name. Every UNIX system has a maximum threshold for this value although it is not typically documented. A good guideline is to keep userids below 16 KB (16384). Every UNIX system ships with a default set of users in the password file. The userids for these users are typically less than 100. A common guideline is to start regular user userids at 100 and increment from there. |
|
|
Numerical identifier for the group to which the user is assigned at log in. The userid guidelines for maximum threshold and numbering policy also apply to the groupid. See Groups. |
|
|
Formal identification of the user. This field usually contains the full name of the user and other information. The field is free form, but cannot contain colons. |
|
|
Home directory of the user. When the user successfully logs on, this directory is the user's current directory. |
|
|
Shell that the UNIX operating system spawns for the user upon a successful login. If this field is left blank, the login shell usually defaults to a Bourne shell, /bin/sh. |
Most common file systems (Berkeley Fast File System, System V) use the concept of file ownership to control primary access to files. UNIX considers every file system entity a file. For example, a directory, an executable, and a database are all considered files. Every file has two kinds of owners: a user and a group.
Ownership of a file gives a user the right to access and set the permissions, also called modes, on the file. The owner of a file can place restrictions on the file to limit access by other users. File permissions and access are explained in File Permissions.
It is sometimes convenient to become a different user to perform some operation on a file that belongs to another user. The superuser can use the su, switch user, command to change to any user without knowing the password. The reverse should never be true. Many implementations further restrict su to root by using an additional control file. See the man page for su(1M) on your system for implementation-dependent information.
A group is a collection of users with common requirements. The group provides a secondary layer of security. For example, the system administrator can create a group for users on a development team to access a test database. Then, the system administrator can set group permissions for the database so that only members of the group can access the file.
Upon login, a user belongs to the group identified in the group field of the user's entry in the password file.
Group information is kept in the group file, usually named /etc/group. Each line in the group file identifies an individual group, just as each line in the password file identifies a user.
The format for a group file entry is a colon-separated list of fields:
Group ownership permits multiple users to access a file based on specified restrictions. While user ownership allows a user to access and set permissions on a file, group permissions only work for access. A user can only change the permissions on a file he owns. Only the superuser can change the permissions on all files.
A single user can belong to multiple groups. However, a user can usually only have the permissions of a single group at any one time.
To change groups, use the newgrp command. If your user name is displayed in the group's entry in /etc/group, newgrp starts a new shell in which you belong to the group specified as the argument to newgrp. If your user name does not appear in the group's entry in /etc/group and there is a password for that group, you must type the group's password to get into that group. Otherwise, newgrp can start a new shell, but without putting you in the desired group. Type id and press the Return key to verify your current group. The newgrp command might behave differently on different systems.
File permissions or modes control access to a file. Every file on a file system has modes associated with it. Only the owner or superuser can set the modes on a file. File modes control three types of permission:
All three permissions are available to all three user types:
The three sets of permissions are organized as:
The first rwx set is for the owner, the second set is for the group, and the third set is for other.
The three sets are often represented as three octal numbers. Where a bit is on, that permission is active. For example, file modes of 750 mean that owner has read, write and execute permission, group members have read and execute permission and everyone else has no permissions on the file. See Changing Permissions and Default Permissions for New Files.
Even though all file system objects are represented as files, permissions differ among different kinds of files, particularly between directories and all other files.
These permissions, however, are contingent on having access to the file's directory. If you cannot access the directory containing the file, you cannot access the file. See Setting Permissions on Directories.
Read permission on a directory grants a user access to the directory's contents. Write permission grants a user permission to create and delete files in the directory, as well as to delete the directory itself. If a user has write permission to a directory that contains another directory that the user does not have write permission for, and the subdirectory contains at least one file, the user cannot delete the directories. The permissions are only active at a single directory level and do not apply to subdirectories of that directory.
Execute permission on a directory provides search permission. If a user also has read permission, execute permission allows the user to change, cd, into that directory.
Read, write and execute and their combinations might behave differently on different systems. Always experiment before relying on a specific permission setting.
When a user creates a new file, the user's umask sets the default permissions for that file. The umask is a set of three octal numerals where each numeral corresponds to a respective set in the file modes. To determine the default permissions for a regular file, perform an exclusive or (XOR) between the umask and 666. XOR the umask with 777 for default modes on a directory. Note that an XOR is really a subtraction.
Example: If a user's umask is set to 002, a newly created file has permissions of
666 - 002 = 664, granting read and write access to the owner and the owner's group, and read-only access to the rest of the world.
A new directory has modes of 777 - 002 = 775, which allows the owner and members of the owner's group to have complete access to the directory, but read and execute access to the rest of the world.
The umask is set with the umask command. This command is usually coded in a user's .profile (for the Bourne and Korn shells) or .login (for the C shell) file.
The command to change permissions is chmod. This command allows two syntaxes for specifying permissions. The first passes the octal number, which represents the modes you want to apply to a file or directory, to the chmod command.
Example: To make the file called tpcatest readable for all and editable only by the owner, type chmod 644 tpcatest at the shell prompt.
The second method uses the character designations for each scope of permission, and the -, + and = symbols to add r, w, and/or x permissions.
Example: Type chmod u=rw,go=r tpcatest at the shell prompt to set the file permissions for the file tpcatest so that it is readable by all and editable only by the owner.
The set-user-id and set-group-id modes are special-use flags that are also pertinent to security. These modes, which can be set on executable files, allow a user to assume an executable's owner or group privileges during execution. For example, if the set-user-id bit on kixclean is set to superuser, when Tony executes kixclean, it runs with superuser's privileges since superuser owns the file. Otherwise, Tony's kixclean runs with Tony's permissions. When the set-group-id bit is set, the executable runs with the executable's group permissions.
You must use the chmod command with octal numbers to set these modes.
Example: To set the set-user-id bit so that kixclean runs with superuser's privileges, type chmod 4755 kixclean at the shell prompt. After you set this bit, the permissions listing for kixclean is -rws r-x r-x. The s in the first group of permissions is the set-user-id bit.
To set the set-group-id bit so that kixclean runs with the group's privileges, type chmod 2755 kixclean at the shell prompt. After you set this bit, the permissions listing for kixclean is -rwx r-s r-x. The s in the second group of permissions is the set-group-id bit.
Refer the man page for chmod(1) for more information about these special modes.
When an entire file system is read-only, it is easier to control access at the file system level rather than on a file-by-file basis.
All mount commands allow superuser to mount a file system read-only. When a file system is mounted read-only, no one, including superuser, can modify any file on that file system. All systems have a file system mount table, most often called /etc/fstab, where you can specify a read-only mount.
Permissions are more complicated when dealing with NFS- or RFS-mounted file systems. The user IDs and groupIDs must often match across systems, not just the user names and group names. This means that user bill on System A must have the same user ID as bill on System B in order for bill, who is logged in to System A, to have permissions on an NFS-mounted file system on System B. Note that each NFS implementation is unique.
Another consideration with NFS-mounted file systems is that generally superuser has permissions of nobody (user)/nobody (group) across NFS mounts. This can cause problems for the system administrator when using NFS to distribute administrative files, because these files almost always belong to superuser.
Sun MTP provides several ways to enforce security at sign-on:
The CESN, CSSN, CESF and CSSF transactions are used to set security attributes for the user, enabling Sun MTP to perform validity checks on each user that submits transactions. See Chapter 2 for more information about the CESN or CSSN login transactions and the CESF or CSSF logoff transactions.
When a user logs on with one of the login transactions, the user ID and password pair is validated with information contained in the SNT or with an external security manager, if one is used. If the validation passes, information from the SNT is merged with information in the Terminal Control Table (TCT). An application program can then access this information using the EXEC CICS ASSIGN command. When the CESF or CSSF transaction is issued at sign-off time, the information from the TCT is cleared, and the external security manager (if in use) is notified.
The SIT contains fields that control password security on a region-wide basis, when using the Sun MTP built-in security rather than an ESM. These fields are ignored when using Sun MTP Secure with an ESM. Password security controls are provided by the ESM.
If this field is set to zero, no password length checking is done.
If this field is set to zero, no password expiration checking is done.
If this field is set to zero, no password failure count checking is done.
Refer to the Sun Mainframe Transaction Processing Software Reference Guide for more information about these SIT fields.
In the PLT you can specify an application program that executes whenever a user signs on to the region. The application program can validate the user and sign that user on to the region. If validation does not occur, the user can be forcibly signed off. Refer to the Sun Mainframe Transaction Processing Software Reference Guide for more information.
When using built-in security, you can configure automatic sign-on by defining users in the SNT. When a user attempts to connect to the region, the user ID is compared with all the entries in the SNT. If a match is found, the user is automatically signed on to the region. If no match is found, the user is signed on with the default permissions: either the default transaction security key or the default user name permissions. Refer to the section on the SNT in the Sun Mainframe Transaction Processing Software Reference Guide.
When using Sun MTP Secure with an ESM, the userid will be associated with the permissions configured with the ESM, independent of whether an SNT entry matches.
You can assign user names in the Terminal Control Table (TCT) for printers and 3270 devices. This associates a device's user name to an SNT entry when it is connected to the region. If a device is configured without a user name, the default security key is used. Refer to the section on the TCT in the Sun Mainframe Transaction Processing Software Reference Guide.
When using Sun MTP Secure with an ESM, those SNT entries must also have a password that authenticates that userid with the ESM. If no SNT entry exists for that userid, that device will be associated with the default userid and its permissions configured with the ESM.
Several Sun MTP communication paths do not provide for or require user sign-on. When an external security manager is not used, all transactions using these communication paths are associated with the default security key (security level 1) unless other user validation is provided. Use of the default security key permits the Sun MTP administrator to limit access to transactions or resources.
|
Note - In addition, the default security key is used for all transactions on all communications paths after a CESF/CSSF/EXEC CICS SIGNOFF for that user's terminal. |
Use the operating environment's security features to secure shell scripts, executables and database files. Set up groups and set the appropriate permissions for each file to ensure that malicious users cannot access or modify files that require protection.
For shell scripts, set permissions to allow only those users belonging to the same group as the shell script files to execute the shell scripts. In this way, users can only execute their group's shell scripts. For example, you can modify Sun MTP shell scripts to automatically set the appropriate environment variables, log the user onto a region and specify the first transaction to execute.
Suggested permission settings for shell scripts:
You can also use group passwords as another level of security when executing a shell script. When a group is set up for password protection, the user must enter the password before executing the protected shell script.
Set permission settings for Sun MTP executables based on your site requirements.
Sun MTP provides two methods to dynamically change a user's password and suspend status in the SNT:
There is also a function that generates encrypted passwords for users.
From time to time, users forget their passwords. The administrator can provide the user with a password that can be used immediately without restarting the region.
1. Type the CTBL transaction to open Table Manager.
2. On the Table Manager menu, press PF5 - Extended Tables.
3. On the Standard Tables menu, press PF5 - Sign-On Table.
4. On the SNT main screen, move the cursor to the name of the user who needs the new password, and press PF9 to display the Security/Accounting screen.
5. When the Security/Accounting screen shown in FIGURE 7-1 is displayed, type a new password in the Password field.
As you type the new password, you can see what you are typing. This means the Password field is unprotected. By default, this field accepts alphanumeric characters and will accept an all numeric password. If you want to require all numeric passwords or all alphabetic passwords, you must set the password type field in the SIT before starting the region. Refer to the Sun Mainframe Transaction Processing Software Reference Guide for information about this field.
6. Press Enter to make the change.
The Password field returns to a protected state.
7. Press PF3 to return to the SNT main screen.
8. Press PF2 to write the change to disk.
9. Press PF3 until you exit Table Manager.
When you press PF2 to save the change, the change is written to disk and the SNT in shared memory is updated. The in-memory SNT is used by the CESN/CSSN transactions for signing on to the region.
Because the operator name in the SNT is unique and is associated with the password, it is used to locate the entry in the SNT and update the password. If you add a new user to the SNT, or change both the password and the operator name for a user, these changes are not made to the SNT in shared memory. You must restart the region for the changes to take effect.
To disable the dynamic password changing feature, you must set the environment variable KIXSNT_NOMEMUPDATE to any value before starting the region. For example:
When dynamic password changing is disabled, you must restart the region before any changes to the SNT take effect.
Sun MTP provides two functions you can call from a secure transaction that change a user's status:
The kx_pw_reset function call takes the following two arguments:
The kx_pw_stachg function call takes the following two arguments:
|
Character value of the new SNT password state: M: User must change the password the next time it is validated |
A program that contains one or both of these functions must be invoked by a secure transaction. Each function checks the Resource Key field in the SNT entry of the user who issues the transaction. The following bits must be set in the user's SNT entry before the function executes:
If the Resource Key of the SNT entry is not valid, no indication is passed back to the user transaction. The function seems to have processed normally (returns 0), but no changes are made to the SNT and the following security validation message is logged:
The functions can result in other errors, even when the Resource Key is correct for the function being invoked:
The following code example shows how to code the functions in a COBOL program.
The kxuser_encryptpw function can be used in an application program to generate encrypted passwords for users. It returns a 13-character encrypted form of the password. You can use this function to add new users and their encrypted passwords to the snt.lst file; then you can import the snt.lst to the snt.tbl format.
char *kxuser_encryptpw(char *puserid, char *ppasswd, char *psalt)
Example: This example shows how to compile and link a C program that returns the encrypted password for a user.
CODE EXAMPLE 7-2 shows a C source file, test.c, that reports the encrypted password returned for the sample user ID, password, and optional "salt."
This program is compiled and linked specifying the shared object library containing the kxuser_encryptpw() function ($UNIKIX/lib/libencryptpw.so). The library is dynamically linked at execution time. The following command shows the options required to compile and link this library on a Solaris platform:
The following example shows the results of executing the compiled and linked program.
When operating in a production environment, restrict certain transactions to privileged users. Restrict transactions that can perform operations that affect all users, but do not restrict transactions such as CESN, CSSN, CESF, and CSSF, which should be available to all users. For more information about the system transactions, see Chapter 2. You can use the built-in transaction security facility or an external security manager through Sun MTP Secure to limit application transactions to specific users. See Chapter 9.
The following subsections describe the built-in transaction security.
Sun MTP controls transaction security through the SNT and the PCT. The SNT contains a 64-bit security key that specifies the classes of transactions the user is authorized to execute. When the user signs on, this security key is merged with information in the user's TCT entry, and is applied to each transaction the user executes.
The PCT contains a number from 1 to 64 in the transaction security (Trans Sec) field that assigns the transaction to a specific class. By default, all transactions are assigned to security class one (1). By default, all users can execute transactions in security class 1.
When a user submits a transaction, the security class is extracted from the PCT entry and used as an index into the security key bit mask. For example, if the user submits a transaction with a security class of 5, the security key is checked to see if the fifth most significant bit is on. If the bit is set, the user is granted access, and the requested transaction executes normally. If the bit is not on, the user does not have access to the requested transaction, and the following message is displayed:
The security key consists of 64 bits in a bit mask. In the SNT, these bits are divided into eight groups of eight characters with the bits numbered from 1 to 8 in the first group, 9 to 16 in the next group, and so on. Each group starts with the low number bit as the leftmost bit.
Example: User Chris Brown needs to use several different types of transactions to complete normal work tasks. The transactions are assigned security classes in the PCT of 12, 38, 42, and 44. FIGURE 7-2 shows the entries to make on the SNT - Security/Accounting screen to ensure that Chris Brown can use the transactions.
In addition to giving the user access to the transactions that are assigned to the security classes marked with X on the screen, the security key given in the example also sets bit 1. This gives the user access to system transactions, provided those transactions have not had their security keys changed in the PCT.
The built-in transaction security facilities are triggered automatically based on how the SNT is configured. Each SNT entry contains an operator name and a Sun MTP user name. The user name of a user entering the region is compared with each user name in the table. If a match is found, the user can execute transactions in security classes for which he is authorized. If no match is found, the user is allowed to sign on, but can only execute transactions with a PCT security class of 1.
If the user wants to sign on as a different user with different privileges, the user can enter the CESN or CSSN transaction with a Sun MTP user name and password. If the user name and password match a user name and password defined in the SNT, the user is signed on, and uses the transaction security classes assigned to the user name in the SNT.
When setting up security, evaluate programs that are defined in the PLT. The CPLT transaction allows programs defined in the PLT to execute automatically when a user signs on to the region. All transactions that are submitted from the terminal, including the CPLT transaction, are checked for security access.
When a client starts, a transaction automatically executes. If the unikix -t option is used, the transaction specified in the -t argument executes. Otherwise, the CPLT transaction executes. In either case, the transaction is subject to security checking just like any transaction submitted at the terminal. Security checking is bypassed by the built-in security features only when transactions are executed automatically by the START command or by a transient data queue trigger. However, when external security is in use, even these transactions are validated.
The Sun MTP-supplied transactions described in Chapter 2 have security requirements that must be considered. These transactions fall into one of two categories:
Unrestricted transactions need to be accessible by all users, whether signed on or not. With built-in transaction security, the default security class in the PCT entries for these transactions is sufficient, and no action is needed. With Sun MTP Secure enabled and an ESM, the following transactions need to have execute permission granted to the default user ID (set in $KIXSECDFLTUSER) and to all UNIX user IDs that connect to the Sun MTP region with the local client (unikix/unikixl):
CESN
CSSN
CESF
CSSF
CSPG
CCIN
CRSR
CPLT
CSMT. If this transaction is used to disconnect users from their terminals, thereby requiring them to have this default access level, it is strongly recommended to also use KIX-COMMANDS SHUTDOWN security to prevent an unauthorized user from using the CSMT SHUT,YES transaction to shut down the region and disconnect all users.
Controlled transactions include all the remaining Sun MTP-supplied transactions. These transactions provide functionality of certain security roles, and need to be grouped so that appropriate permissions to execute them are granted only to authorized users. The following table shows an example of how to group these transactions. Your site might have different requirements.
With Sun MTP built-in transaction security, the PCT entries for these transactions should have a security class assigned representing the role, and the authorized users' SNT entries should contain that security key. With Sun MTP Secure, the ESM should have these roles and permissions defined.
The examples in this section show how to apply operating environment and Sun MTP security techniques to control access to applications and files. The degree of security is determined by the environment; a production environment requires more security than a development environment.
FIGURE 7-3 shows a region with a finance application and an accounting application.
The users for the sample region have the following access requirements:
There are several methods for controlling user sign-on security: group ID security, the CESN or CSSN transaction or a user-supplied security transaction. The examples in this section illustrate each method.
Assign users to a group, depending on the access permissions required. For example:
The group ID names are defined in the /etc/group file as:
fin::123:uf1,uf2,...ufn,admin acct::124:ua1,ua2,...uan,admin finacct::125:ufa1,ufa2,...ufan,admin unikix::200:admin |
Users are defined in the /etc/passwd file as:
For each group, the admin user modifies the Sun MTP sign-on script to execute a specific sign-on transaction that enters a specific group's users into the appropriate application. The permissions on each sign-on script are set so that only the specified group can execute it. In addition, the system administrator can edit the /etc/password file so that the modified sign-on script executes automatically when the user signs on. For example, if the sign-on shell script is /mtp/mtp80/bin/shell.grp1, the entry in the password file is:
ufa1::305:125:Bill Ray:/user/ufa1:/mtp/mtp80/bin/shll.grp1
You can impose an additional level of security by assigning passwords to the group ids and not signing on the user to that group. Then, the user must execute newgrp to join the group.
Use the CESN and CSSN transactions to verify that a user has permission to log in and execute transactions. Use the CESN or CSSN transaction with group id security.
The system administrator either modifies the sign-on script with the appropriate permissions indicating that the CESN or CSSN transaction is the first transaction to execute on behalf of the user, or modifies the PLT to require the execution of the CESN or CSSN transaction each time a user signs on. See Chapter 2 for more information about the CESN and CSSN transactions and refer to the Sun Mainframe Transaction Processing Software Reference Guide for information about the PLT.
The system administrator can provide a site security transaction that is executed each time a user signs on. The transaction asks the user for information, then checks the information against a file that contains the valid data. If the check is invalid, the user is signed off. The PLT specifies the security transaction that is to execute each time a user signs on.
The system administrator must protect shell scripts and executables so that users cannot accidently or maliciously corrupt, or in some cases, read the files. For example, the shell scripts that are used to log a user onto a region must not be readable or executable by users not in the same group. Set up the region to secure the system.
Example: Set the permissions for shell scripts used for sign-on.
The system administrator can set the permissions to allow only the administrator to initiate a region, or to allow any user to initiate a region.
Example: A production environment requires that only the system administrator initiate a region. Set the permissions so that no development system can execute on the production system unless it is initiated by the system administrator.
Example: If both production and development regions must run on the same system, set the permissions to allow users in other groups to initiate a region.
To secure the database files A1, A2, A3, F1 and F2 shown in FIGURE 7-3, create the files with the appropriate permissions (for example, 760) and assign the files to a group (e.g., finoff) that is different from the users' group(s). The permissions indicate that only the owner and users belonging to the finoff group can read and write the files; all others have no permissions. In this way, the region is initiated by the administrator under his primary group, allowing the region to execute under the finoff group and access the files.
The Sun MTP transaction security system controls which users can execute which transactions. To implement the transaction security requirements described in the beginning of this section, make the following modifications to the SNT and PCT:
In the PCT, assign classes to the transactions as follows:
In the SNT, assign classes to users as follows:
| Sun Mainframe Transaction Processing Software Administrator's Guide | 816-5327-11 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
To Provide a User With a New Password