SCO UnixWare 2.1.0 C2 Installation Cover Letter The purpose of this document is to describe how to install and configure your system so that it will match the configuration submitted for evaluation at ITSEC security level C2. Table of Contents 1. Software 1 2. Verifying Software Authenticity 2 3. Installation Procedure 2 4. Additional Configuration 4 5. Users 6 5.1 Additional Notes on Creating Users 6 5.2 Deleting Users 6 5.3 Deleting Groups 6 6. Maintaining System Security 7 6.1 System Administration 7 6.2 Hardware 11 7. Documentation Notes 11 7.1 Documentation Errata 12 7.2 Software Errata 13 1. Software Operating System (UnixWare 2.1 Application Server) Software Development Kit With the following Ptf's PTF Description Ptf3385 SCSI Tape Driver Update Ptf3015 Year 2000+ Update Ptf3028b Performance Enhancements for UnixWare 2.1 Ptf3004 NWS Kernel Tuneable Ptf3384 STREAMS Driver Update Ptf3037 Patch for m320 Mouse Driver Ptf3063 Exec() System Call Security Supplement Ptf3124e Enhanced adsl Driver Ptf3209b Emergency Recovery Disk Supplement Ptf3141b Video driver Supplement Ptf3256 Replacement Installation Diskette and Installation Supplement Ptf3383b Evaluation Security Supplement=20 The Ptf's listed above are not provided with the UnixWare 2.1.0 media kit. They can be obtained via ftp from www.sco.com, or from SCO support. Your media kit will also contain the following software that is not part of the UnixWare 2.1.0 C2 installation, and must not be installed. Two (2) Network Installation Utilities Diskettes (Volumes 1 and 2) One (1) DR DOS Bootable Diskette One (1) Java Development Kit 1.1 CD-ROM SCO UnixWare Enhancement Products Eval CD-ROM SCO UnixWare 2.1.1 Update SCO UnixWare 2.1.2 Update SCO Internet Enhancements, which includes Netscape Navigator Netscape Navigator Gold Netscape Fast Track Server SCO PPP from Morning Star SCO ARCserve / Open from Cheyenne Lite The box that the media arrives in will say version 2.1.2. This is due to the 2.1.2 update also being distributed in this media kit. The 2.1.2 update listed above is excluded from the UnixWare 2.1.0 C2 installation. 2. Verifying Software Authenticity Your SCO UnixWare 2.1.0 software and manuals will have been delivered to you shrink-wrapped. You should check when you receive them that the shrink-wrap is intact, and you should check for the presence of the Certificate of Licence and Authenticity, with the SCO hologram affixed. If this is not the case, you should contact your distributor before continuing with the installation. To verify the authenticity of the additional software diskettes and Ptf's, you should contact your SCO support representative, who will provide you with a list of diskette names (where appropriate) and checksums, which you can use to check the authenticity of your diskette copies and Ptf's. 3. Installation Procedure Before beginning installation, you should ensure that you have noted the documentation errata specified and referred to in section 11 of this document. You are advised to mark up your documentation set where changes are necessary. If the Ptf's were downloaded from www.sco.com some of them will require some additional preparation prior to installation. The Ptf's listed below need some preparation, and full Instructions are provided in the text (.txt) file that accompanies the Ptf. Alternatively these Ptf's can be obtained from SCO support ready for installation. Ptf3256 Replacement Installation Diskette and Installation Supplement This Ptf is 2 floppy diskettes. One is a replacement for the SCO(r) UnixWare(r) Installation Diskette, and should be used to boot the system prior to installation. The second diskette is an installation supplement disk that the installer will be prompted for during installation. Ptf3124e Enhanced adsl Driver This is a single floppy disk. A prompt will appear "Install Another HBA diskette". This diskette should be installed at this time. After the diskette has been installed, install the SCO(r) UnixWare(r) Host Bus Adapter Disk. During installation the user is invited to choose between default and custom installation mode. As not all the default packages are required (some of them must be excluded) the user must opt for custom installation mode. The following packages that would be included by default are specifically excluded from the C2 evaluated installation. * Internet Utilities (tcp/ip) * NetWare Networking=20 * NetWare UNIX Client=20 * Network Interface Card Support * Network Management=20 The following packages that would not be included by default must be installed for the C2 evaluated installation. * Access Control Lists * Auditing * OA&M * Desktop and Owner Handbooks1 * All User and Admin documentation1 * DynaText Document Browser1 * Traditional Manual Pages.1 * Optimising C Compilation System2 If you are installing a multi-processor system then additionally select * OS Multiprocessor Support After the package selection has taken place, the installation will proceed automatically. The installer should follow the on screen prompts, but should not otherwise interfere with the machine under installation. Towards the end of the installation the installer will be prompted for passwords to the root and owner accounts. It is important that passwords are selected at this prompt so that the system is not left in an insecure state. When the system has been installed and has rebooted, the installer must check that all of the packages selected during installation have installed successfully. To do this use the pkginfo (1) command. Each of the package descriptions contains a status field this should read, STATUS: completely installed. If this is not the case, then the package should be removed and re-installed. When the installer is satisfied that the base installation is complete the software development kit (sdk) can be installed. Follow the installation instructions in the sdk media kit. When installing the sdk, do not select the Network Management SDK. This component requires other networking components that are not part of the evaluated platform. All other components of the sdk should be installed. After the system has been installed, the following Ptf's must also be added immediately, PTF Description Ptf3385 SCSI Tape Driver Update Ptf3015 Year 2000+ Update Ptf3028b Performance Enhancements for UnixWare 2.1 Ptf3004 NWS Kernel Tunable Ptf3384 STREAMS Driver Update Ptf3037 Patch for m320 Mouse Driver Ptf3063 Exec() System Call Security Supplement Ptf3209b Emergency Recovery Disk Supplement Ptf3141b Video Driver Supplement Ptf3383b Evaluation Security Supplement * The Evaluation Security Supplement must be installed last, after all of the other Ptf's and the sdk have been installed. Each of the Ptf's come in two parts. A file labelled ptfxxxx.txt and a file labelled ptfxxxx.Z. The installation instructions and a description of each Ptf are contained in the ptfxxxx.txt file. These installation instructions should be followed for each Ptf in turn. 4. Additional Configuration At the end of the installation, the accounts listed in /etc/passwd will have been created without audit masks. This should be corrected as soon as possible after installation. To correct this log into the system as the root user, and issue the following commands, #usermod -a +id_auth,dir_make,file_make,device Where login is each login in turn found in the /etc/passwd file. Any additional user accounts created will automatically be created with the audit masks id_auth, dir_make, and file_make. This is controlled by the AUDIT_MASK variable in /etc/default/useradd. The bad_auth audit event must be switched on system wide, not just for individual users. To do this, use the auditset(1M) command. As the root user, #auditset -s +bad_auth In order for the bad_auth event to be audited automatically, after each time the system is rebooted, it is necessary to add the following line to the /etc/rc2.d/S02audit script. /usr/sbin/auditset -s +bad_auth This line should be added to the 'start' section of the script immediately after the check that ensures auditing has successfully started. The file /etc/inittab controls how the system behaves in various operational modes. It is therefore important to keep a backup copy of the file and to ensure it is not tampered with. The backup copy of /etc/inittab should be stored on a floppy disk that can be stored separately from the system. To ensure that the /etc/inittab file is not tampered with use the sum(1) command. # sum /etc/inittab 20780 6 /etc/inittab Make a note of this information and store it in a secure place along with the backup copy of /etc/inittab. The output from sum shown above is an example, it may be different on your system. This does not indicate an installation problem, what is important is that the sum of /etc/inittab does not change after the initial installation is complete. Periodically, you should run sum again and verify that the sum of /etc/inittab has not changed. The su(1M) command is not secure enough to be used on an evaluated system. The su(1M) command should be restricted to use by the root user only. To achieve this change the permissions on the su(1M) utility. # chmod 700 /sbin/su # chmod 700 /bin/su NOTE: When sections 1 through 4 are completed, the system is securely configured. Sections 5 and 6 should be followed to help maintain a secure system. 5. Users 5.1 Additional Notes on Creating Users All users of the system should each have a new account created for them. When creating a user account, do not reuse any of the account names or user id numbers that are already assigned by the system (the useradd (1M) utility will show a warning if you attempt to do this, and fail). You must not assign more than one account to any user. When creating a user account, do not assign that user to any of the groups that are already defined on the system as shipped, except the group "group". You may create new groups to include your users in as you wish. When creating a new group, do not use any of the group id numbers that are already in use (the groupadd (1M) utility will show a warning if you attempt to do this). Finally, note that when a user account is retired, that user may still have batch jobs enabled (see the manual pages for the commands at and cron). These batch jobs should be deleted manually. Issuing the command usermod -d -m has the effect of changing the ownership permissions of all files in directory to that of the . Usermod(1M) is only available to privileged administrators, but the administrator should check the contents of before issuing the command. 5.2 Deleting Users If a user is no longer authorised to use the system, the users account is locked, but the user must not be deleted from the system. If the user's userid is deleted from the machine, it is difficult to make accurate use of historical auditing information. If a user's account is locked, and will no longer be used the administrator may wish to tidy up any files that the user had. These files may not necessarily be under the user's home directory. To find files that the user owned use find(1M) -u . To delete the files use rm(1M) or use chown (1M) to change ownership to another user. 5.3 Deleting Groups Groups should not be deleted from the system when no longer in use. If group information is no longer available then it is hard to interpret some aspects of the audit trail. If a group becomes redundant change the objects in a group to become part of another new group, or delete them from the system. To find these objects use find(1M) with the -g option. To change the group permission on a file use chgrp (1M). 6. Maintaining System Security 6.1 System Administration 1. After deleting a user account and at other times, checks for processes from a user whose account has been revoked should be made: ps -ef Will show processes with numeric uid in first column instead of login name. The second column has its process ID , to remove the process type: kill -9 2. Periodic checks of the file access permissions of /etc/shadow should be made to ensure it remains protected. ls -l /etc/shadow Should show: -r-------- 1 root sys 2004 Nov 22 09:42 /etc/shadow 3. Periodic checks of the file access permissions of /etc/group should be made to ensure it remains protected. ls -l /etc/group Should show: -rw-r--r-- 1 root other 357 Oct 25 20:34 /etc/group 4. Periodic checks should be made on disk usage by using the df(1M) command to ensure that the file systems are not becoming too full such that the system becomes unusable or that the audit trail cannot function. df -k will produce a display of disk partition usage (for example): filesystem kbytes used avail capacity mounted on /dev/dsk/c0d0s7 53333 47200 6133 89% / /dev/dsk/c0d0s8 131127 110767 20360 84% /usr /dev/dsk/c0d0s10 50868 22973 27895 45% /home Inspect the last column for required mount point, the fourth column shows number of bytes available and the fifth column the partition capacity used. 5. Periodic checks should be made on the file access permissions of the accountability files as follows: ls -l /usr/sbin/audit* ls -ld /etc/security/audit ls -l /etc/security/audit/classes ls -l /etc/security/ia/audit ls -l /etc/default/audit ls -l /etc/init.d/audit ls -ld /var/audit ls -l /var/audit/* ls -l /var/audit/auditmap ls -l /var/audit/auditmap/* 6. Follow the advice given in Chapter 27-3 (Using pkgchk to Verify Audit Software Installation). The file permissions displayed should agree with those listed in Table 27-1. When the Administrator sets privileges these should be checked before and after setting by using the filepriv(1M) command without any options to display the privilege settings. See Chapter 23 - Privileges and the Filepriv Command 7. If a user reports a failure to login with a username and password he believes to be valid the authentication system should be checked as shown under other headings in this note. login password If a 'Login incorrect' message is displayed, it may indicate that a third party has changed the password. 8. When users login, they should be advised to check that the time of the last login displayed corresponds to the time they actually logged on. Any discrepancy may indicate that an unauthorised person has used the login. 9. Periodic checks for unauthorised access to the /etc/shadow and /etc/group file should be performed as follows: auditrpt -f /etc/shadow auditrpt -f /etc/group There should be no suspicious pattern of access to the file by non-privileged users (for example, many repeated accesses). 10. Periodic checks should be made for use of an inactive or temporary user's ID. For example: auditrpt -u userx Any activity reported should be regarded as suspicious if userx is not expected to be using the system (for example on holiday). 11. Periodic checks on an inactive or temporary user's objects should be made as follows: auditset -s open_rd,open_wr At a later time, run auditrpt to see accesses to the named user files. For example: auditrpt -e open_rd,open_wr |grep "/home/userx" 12. Periodic checks should be made for repeated failed attempts to login: auditrpt -e bad_auth Many repeated failed attempts to login with the same login name may indicate the password being guessed. 13. Periodic checks should be made to check access to a user at unexpected times. For example, to display audit trail information about a user produced outside the working day: auditrpt -u -s -h 14. Periodic checks should be made for reading from, writing to, and changing access permissions of sensitive files by setting the file_access and dac audit criteria and then at a later time running auditrpt as follows: auditset -s file_access,dac auditrpt -f Any accesses other than by a privileged user or owner of the sensitive file should be treated as suspicious. Sensitive files are /etc/shadow, /etc/group, /var/audit/*, all files under the /etc/security directory and any files which the system administrator may nominate for the site. 15. Periodic checks should be made on the list of users as follows: passwd -s -a The list of users and their password attributes should agree with expectations. Any discrepancy should be treated with suspicion. 16. Periodic checks should be made for unauthorised introduction of new users by running auditrpt as follows: auditrpt -e add_usr Addition of new users should agree with expectations. 17. Periodic checks should be made of the file access permissions of /etc/security/tcb/privs file: ls -l /etc/security/tcb/privs should produce : -r--rw-r-- 1 sys priv 28255 Oct 29 14:55 /etc/security/tcb/privs Any difference in access permissions or in owner or group should be treated with suspicion. 18. An unusually large number of audit trail logs generated in a single day should be investigated for possible misuse of the system. 19. A message indicating that auditing is not enabled because the maximum number ofaudit log files already exists for today, should be investigated for possible misuse of the system. Such a message would be given when auditing is switched on or when the machine is rebooted. 20. Periodic auditing to establish regular patterns of use should be carried out. For example: auditrpt -u -e id_auth Could be used to establish normal times of logging in and out during the day. Any large deviation from an established pattern should be monitored for possible misuse of the system. 21. Periodic checks should be made to the TFM database by calling: adminuser | pg The list of users with privileged access to commands and roles should agree with expectations. 22. Periodic checks on the use of privilege within the system should be performed as follows: auditset -s tfadmin,file_priv auditrpt -e tfadmin,filepriv Note that the pm_denied event could also be added to this list, but very many event records are generated due to normal system usage and suspicious patterns are hard to detect. 23. Periodic checks should be made that audit log files end at the expected times and with the normal sequence of records. 24. The administrator must not use usermod -l to change users log name after it has been set. For two reasons, 1. Files owned by the old log name may be left discarded on the system. 2. The historical auditing records would be hard to understand in the same way that a deleted users are. 25. It is important that the system processor is protected such that unauthorised staff cannot get access to the floppy disk or tape drives. This is to prevent staff introducing unauthorised software to the installation or making unauthorised archives of software and files stored on the system. 6.2 Hardware The system processor should be protected in such a way that unauthorised staff cannot make changes to the system processor after installation. Any external drives (floppy disk, tape drives, CDROM) should be protected so that unauthorised staff cannot introduce unauthorised software via them, or use them to make unauthorised copies of files. Some terminals have the facility to print output from the terminal screen locally. This presents a potential security hazard when typing passwords at a terminal screen. Terminals with a print facility should not be used in a secure installation. 7. Documentation Notes The following are pointers to information relevant to users of a secure system. All of this information may be viewed on line with the Dynatext Document viewer, and can be found in the System Administration Handbook. * Information on Security mechanisms visible to users can be found in section 2. * Managing passwords including ageing and expiry can be found in Section 7. * Information on ACL's and Discretionary Access Control can be found in Section 17. * General information on security administration can be found in sections 24 and 25. UnixWare 2.1 has a 2GB file size limit. The maximum size of an individual auditlog must be less than 2 GB. Audit log switching allows multiple audit logs to be used. See auditlog (1M) for further details regarding auditlogs. When the "Access Disks, Tapes, etc" permissions are given to a user account, it simply means the user can mount and unmount file systems. UserSetup (on the graphical desktop) adds and removes these privileges correctly. The user can access the tape and floppy drive to make backups. However, the system processor should be protected such that only authorised personnel can place media in these drives. The graphical lock programs xlock and xidlelock only protect the graphical login screens. They do not protect any console or virtual terminal sessions. If a user is away from the console they must logoff first, if using the virtual terminals or the shell login. 7.1 Documentation Errata 1. Audit event sched_rt in table 28-11 of the System Administrators Handbook is not applicable and should not be included in the documentation. Table 28-18 Processor Binding Events should also include lwp_kill send a signal to a sibling lightweight process _lwp_kill (2) N lwp_exit terminate the calling LWP _lwp_exit (2) N 2. The login parameters for DISABLETIME, LOGFAILURES, SLEEPTIME and MAXTRYS apply equally to the desktop and command line login. The login(4) manual page describes these parameters. The defadm (1M) command can be used to modify these parameters. For example #defadm login DISABLETIME=3D10 LOGFAILURES=3D2 SLEEPTIME=3D5 MAXTRYS=3D2 would set DISABLETIME, LOGFAILURES, SLEEPTIME and MAXTRYS for both the command line and desktop logins. In the case of the graphical desktop, if the login parameters are changed, it is necessary to restart the graphical login after the login parameters are changed. This can be done as follows. At the graphical login screen click on the Exit button with the mouse. The graphical login will disappear and you will be returned to the command line screen. Log in as root and type, # start_glogin The graphical login will appear on the screen. Remember to switch back to the command line login and log out. 3. Users working at the system console should take care to ensure that they are logged out at both the graphical and console logins when they end their session. 4. When using the tar(1M) command the Set-UID bit and any Access Control List (ACL) is lost. Tar (1M) should not be used to archive files with ACL's. The set-UID bit can be re-applied where necessary to the restored files. 5. When using the cpio (1M) command the Set-UID bit is lost. The set-UID bit can be re-applied where necessary to the restored files. 6. ACL information can only be attributed to files in the vxfs (version 2) or sfs file systems. Files that are copied to/from the sfs or vxfs (version 2) to any other file systems will loose any ACL associated with them. 7.2 Software Errata 1. If auditlog(1M) is given an invalid -v option argument, it prints the following error message: Audit Buffer High Water Mark Must Be >=3D 0 or <=3D bytes. It should read, Audit Buffer High Water Mark Must Be >=3D 0 and <=3D bytes. 2. Sulogin (1M) should not be run from the command line. Sulogin is automatically invoked by init during system start-up. If it is invoked from the command line it will respond with a prompt Type Ctrl-d to proceed with normal startup, (or give root password for Single User Mode): if the root password is entered, the message Entering Single User Mode This message is incorrect. The system is still in multiuser mode. 3. auditrpt (1M) -f option cannot be used reliably to find all instances of a file's records. auditrpt -f requires a full hierarchic pathname. If auditing cannot determine the full pathname it inserts `*/terminal-filename' instead. This causes 'auditrpt` to fail. Under this circumstance important events may be recorded that cannot be retrieved easily. This restriction is documented in the auditrpt (1M) man page, and in the Displaying Audit Trail Information chapter of the online and printed systems Administration Volume 2. 4. When n failed logins are performed at the Desktop login window (and n reached the limit set by the LOGFAILURES parameter), only n-1 failed login attempts were recorded in the file /var/adm/loginlog. The correct operation should be that n login attempts are recorded. It should be noted that any failed login attempts recorded in this file could indicate somebody attempting to gain unauthorised access to the system. In any case, each failed attempt will be recorded in the audit logs. 5. The Desktop login, the console login and any connected terminals keep a separate failed login count. All failed logins are recorded in /var/adm/loginlog, subject to the restriction stated in point [4] above. 6. If you need to set dates for any purpose (for example user account expiry, or batch jobs) after the year 2000, it is necessary use the following long date format. For example, usermod -e "January 10, 2000" Note the " ", as these are necessary. If you enter dates after the year 2000 in the format 01/10/00 you will not get the result you expected. When entering dates for account expiry or batch jobs, ensure that you are entering the date in the correct format for the locale you are in. For example, in the United States, dates are entered in the format mm/dd/yy (month/day/year) in the United kingdom dates are entered in the format dd/mm/yy. Entering dates in the wrong format for your local may result in user accounts not expiring at the expected time, or batch jobs being executed at the wrong time. 7. Specifying batch jobs with the at (1) command has a similar problem to that of the expiry date described above. To set a batch job to execute on October 22 2001 at 14:20 requires an at (1) date in the following format CCYYMMDDhhmm, so as an example, we could do the following, Cat /tmp/x > /tmp/y | at -t 200110221420 This command will cat /tmp/x and redirect it to /tmp/y on October 22 20001 at 14:20. 1 These are included for ease of access to information about the system. 2 Required for complete installation of the SDK. SCO UnixWare 2.1.0 C2 Installation Cover Letter Issue 2.3 1/12/98