POLYCENTER Security Compliance Manager (CM) Version 2.5 Revised: 13 May 1996 ------------- Release Notes ------------- Except where noted otherwise, POLYCENTER Security CM refers to each of the products: POLYCENTER Security CM for AIX, POLYCENTER Security CM for HP-UX, POLYCENTER Security CM for SunOS, POLYCENTER Security CM for Solaris 2, POLYCENTER Security CM for Digital UNIX and POLYCENTER Security CM for ULTRIX. These release notes contain information on the following topics: o Product defects fixed since V2.4 o Importing/Exporting the Required Inspector o Importing a Required Inspector created using an earlier version of CM o Configuring your system to use a passthru server o User interface issues o Known bugs in this release Note Where references to files supplied with POLYCENTER Security CM contain {PRODUCT-DIR} in the directory specification, the {PRODUCT-DIR} is one of: ------------------------------------------------------- {PRODUCT-DIR} Operating System Architecture ------------------------------------------------------- SAR250 AIX RS/6000 SOA250 Digital UNIX Alpha SHP240 HP-UX PA-RISC SLS250 Solaris SPARC SSS240 SunOS SPARC SUR240 ULTRIX RISC SUV240 ULTRIX VAX ------------------------------------------------------- [ ] Product defects fixed and other changes since V2.4 The following defects have been identified and fixed since the release of V2.4 o A number of commands changed location on AIX V4.1. As a result some of user_written_program scripts, supplied with the kit, were updated by removing the explicit command pathnames and inserting a PATH definition. o The password lifetime & password length value specification moved from /etc/security/login.cfg, in AIX V3.2, to /etc/security/user, in AIX V4.1. The password_lifetime & password_length test primitives have been updated to handle this relocation. o Mailing reports failed on AIX V4.1. This has now been fixed. o An exclusion list has been added to the suid_script primitive. The exclusion list is specified, using the suid_script key, in the configuration file diu_config.required. o The installation on Solaris V2.4 incorrectly determined if the ammount disk space was sufficient to install the CM. This is now fixed. The following is the list of problems that have been fixed for CM V2.5 for Digital UNIX. o There is no longer a problem with the ps command in the scp file and inspectsetup, thus removing the need for the current patch. o The requirement to include a dummy dnet_spawner has been removed. o The operating system version check has been updated to include installation on Digital UNIX V4. o The echo problem in the install & inspectsetup on Digital UNIX V4 is now fixed. o The access_notice primitive no longer crashes the inspect daemon if less than 4 fields exist on a line in /etc/gettydefs. o A token is no longer sent on importing the RI. o The correct path is always used with suid_in_root_path. o The Default File Permission inspector is now removed from the kit. o The Practical UNIX Security inspector is now shipped with the lockdown flag set to disable. [ ] Importing/Exporting the Required Inspector There are some restrictions associated with the import/export facility in the POLYCENTER Security CM setup utility, inspectsetup. These restrictions affect the copying of the Required Inspector between systems of different architectures (e.g. an RS/6000 running AIX, and a VAX running ULTRIX). The following points should be noted: o When a Required Inspector is exported to a system of a different architecture, a new Policy File ID (PFID) will be generated for the inspector on the new system. In order to maintain a common PFID for systems of the same architecture, export a different RI from each architecture of interest. For the purposes of the above discussion, VAX and RISC (MIPS) are distinct architectures. o When a Required Inspector is exported from a big-endian system to a little-endian system, or vice versa, the imported inspect CRC database appears corrupt on the new system. (This is because the CRC generation algorithm is byte-order dependent.) The import procedure in the inspectsetup utility asks you if you want to update the CRC database. If your Required Inspector has not crossed the byte-order boundary, answer no. Otherwise answer yes. (Note, the "endian-ness" of an architecture refers to the order in which bytes are stored on a system of that architecture. VAX and RISC ULTRIX systems are little-endian; the other supported platforms -- RS/6000, PA-RISC and SPARC -- are big-endian.) Because of the restrictions mentioned above, and because inspectors on different platforms tend to be slightly different (e.g. the files and default accounts tested will be different), it is recommended that you do not export Required Inspectors across different platforms (except possibly VAX and RISC). The preferred solution is to use the inspector compiler to generate a platform-tailored Required Inspector on each platform from a single source file. This source file can be compiled on one system of each architecture, and the Required Inspector then exported from each platform. [ ] Importing a Required Inspector created using an earlier version of CM If you import a Required Inspector (RI) generated using POLYCENTER Security CM for DEC OSF/1, Version 2.4, then the Policy File Identifier (PFID) is updated the first time the inspector is executed. Workaround: This only applies to the person generating or maintaining the RI. On upgrading to POLYCENTER Security CM for Digital UNIX, Version 2.5 perform the following steps: o Import the Required Inspector, using inspectsetup o Execute the Required Inspector o Export the Required Inspector, using inspectsetup This version of the RI will now run successfully on both POLYCENTER Security CM for DEC OSF/1, Version 2.4 and POLYCENTER Security CM for Digital UNIX, Version 2.5 without any modification to the PFID. [ ] Configuring your system to use a Passthru Server When configuring your system to send tokens to POLYCENTER Security Reporting Facility (SRF) for VMS via a passthru server, you need to specify the passthru nodename carefully, as follows. The nodename you specify is stored in the file /usr/var/kits/{PRODUCT-DIR}/database/diu_token.conf (along with other information - see the user guide for details of the format), and is used by POLYCENTER Security CM as follows: o it is used as the TCP/IP nodename of the node to which to send the token for subsequent transmission to POLYCENTER Security SRF; and o it is included as a field in the token itself. POLYCENTER SRF uses this information in a different way: it uses it to determine the e-mail address of the root account on your system. Specifically, it assumes that the passthru nodename it receives in the token is a DECnet nodename, and so it generates the address as ::"root@" For this to work, the DECnet nodename of the passthru server must be an alias of the TCP/IP name of the passthru server in your hosts database; and it is this alias that you must specify as the passthru server nodename to the installation or to the POLYCENTER Security CM setup utility. For example, if the passthru node has the DECnet name "snoopy" and the TCP/IP name snoopy.peanuts.com, then you should define snoopy as an alias for snoopy.peanuts.com in your hosts database, and then specify snoopy (and not the fully qualified snoopy.peanuts.com) as the passthru nodename. [ ] User interface issues On installing POLYCENTER Security CM for the first time, you may have to run the rehash command before invoking inspect. This is because the shells build up hash tables of the programs in your PATH when the shell is started, so new programs do not get seen until your next session (or until you execute a rehash). There is a problem with the display when running POLYCENTER Security CM while logged in over DECnet (using dlogin) to a system running DECnet V4.0 or DECnet V4.1. The problem is that keystrokes appear to be buffered until a carriage return is sent. The effect of this is that when using accelerator keys, the operation selected is not highlighted. However, when Return is pressed, the correct selected operation (and not the highlighted one) is performed. This can be confusing! Because the POLYCENTER Security CM character cell user interface is based on the portable curses routines, the TERM environment variable should be set correctly according to the terminal type. For example, on an OpenWindows cmdtool window, it should be set to "sun-cmd"; on a DECterm, it should be set to "vt100". This can be set as shown in the following example: From the C shell: setenv TERM sun-cmd From the Bourne shell: TERM=sun-cmd Also, the tabs should be set correctly using the following command: % stty sane On HP-UX hpterms, you may also need to execute the following command: % eval `/usr/bin/X11/resize` This sets the ROWS and COLUMNS environment variables that are needed to correctly take advantage of the full hpterm window. "Stray" vertical lines occasionally appear on the POLYCENTER Security CM for SunOS screen. These may be cleared by entering ^L (CTRL/L). There is an issue related to the User Interface on POLYCENTER Security CM for AIX only. This arises when running POLYCENTER Security CM while remotely logged into an AIX system (using rlogin). Because of a problem with the timing of the escape sequence as it arrives from the net, the arrow keys may not be recognised as valid keystrokes. This may be remedied by increasing the value of the ESCDELAY environment variable from its default value of 500. A value in the range 900 to 1000 has been found to be suitable. [ ] Known Bugs in this release The following known bugs exist in this release of POLYCENTER Security CM. o dtterm on AIX The use of a ddterm on AIX may result in the interface incorrectly calculating the window size. As a result some fields may wrap around to the next line. Workaround: Use an aixterm. o Inspector compiler The following error may occur when compiling an inspector: >>> ERROR: bad option value; at or near the string `"Jan 01 00:00 1970"' in line 110 Workaround: Remove the start time definition, %StartTime, from the compiler file. Alternatively choose the appropriate format for the date. o UID range on AIX The uid_range test primitive fails to report on negative UIDs on AIX. The password_file_format test primitive does however correctly report on them. Workaround: None. o umask and file access The umask test primitive incorrectly assumes that if it cannot access a particular user's startup file (e.g. .cshrc), then that file does not exist. Hence, it may generate incorrect reports about a user's umask setting. Workaround: None. o Pressing Return on invoking inspect On ULTRIX only, if Return is pressed between the time POLYCENTER Security CM is invoked and before the initial screen appears (a period of less than a second, typically), no output will be displayed. Workaround: Do not press Return until the first screen has appeared. If you do encounter this problem, you may quit using Control/C.