Date:   29 December 2003 

Fixpack:  4.1-PDO-0004

Component:  Tivoli Access Manager for Operating Systems (AMOS)


General Description:

    This fixpack contains several fixes for problems in the various
    components that comprise the AMOS software. This fixpack requires 
    Access Manager for Operating Systems 4.1.

    This fixpack includes all AMOS 4.1 fixes after the main release. 

Platform support added since main release:

    AMOS supports additional Linux kernels with 4.1-PDO-FP02 and higher
    installed.  (including this fixpack) 
      
    AMOS supports the Solaris 2.9 and AIX 5.2 platforms with 4.1-PDO-FP01
    or higher installed (including this fixpack)


Problems Fixed in 4.1-PDO-0004:

    APAR IY45392
    Symptom: AIX Only.  With xmalloc debug enabled, system crashes due to
             write of memory that has been freed.  A crash evaluation may
             show that kpcf_asyncLUReq is the culprit.
 
    APAR IY46330 (Originating APAR: IY45776)
    Symptom:  HPUX 11i 64 bit systems.  With patches that supercede HPUX 
              PHCO_24400, applications that use 32 bit API calls can
              cause AMOS to produce errors.  This is due to HP not zeroing
              the upper 32 bits of the 64 bit register.  This defect can
              manifest itself with many applications.  Some examples of 
              failures include:  cp * /tmp; passwd; applications that do
              process creation.   This is a critical fix for HPUX 11i 64 bit
              systems running AMOS 4.1.

    APAR IY46764
    Symptom:  All Platforms.  AMOS did not evaluate policy with wildcards 
              correctly.  an example:  restrictive policy is defined on 
              /usr/*/test.  File access denials did not occur.   

    APAR IY46821
    Symptom:  HPUX patch requirements are incorrect in the 4.1 release notes. 
              See below for more information.
 
    APAR IY46893
    Symptom:  pdoscfg does not allow blanks in the suffix.  You can now  
              configure AMOS an LDAP suffix with spaces, contained in
              quotes. 

              example: pdoscfg -suffix "o=your company,c=us" 

    APAR IY47162
    Symptom:  Solaris 2.8 patch requirements are incorrect in the 4.1 release 
              notes. See below for more information.

    APAR IY47837
    Symptom:  Solaris only:  Error in pal_fbaseGetRawFidAndAttrs() produces
              system crash.

    APAR IY47898  
    Symptom:  Solaris only:  NULL pointer passed to VFS_VGET causes
              system crash.

    APAR IY48146  
    Symptom:  Solaris and HPUX:  Slow socket service processing with
              TCP STREAMS. When sockets are quickly opened and closed, AMOS
              missed the socket close event.  AMOS waited until a timeout
              period to try again.  AMOS now checks the socket for the close
              event.

    APAR IY48283  
    Symptom:  AIX and Linux:  NetIncoming policy not enforced correctly.
              With restrictive NetIncoming policy applied to specific ports, 
              a correct authorization decision is made (Denial) but access to
              the port was still allowed. 

    APAR IY50082
    Symptom:  DOCUMENTATION APAR (See 4.1-PDO-FP04.README).  Incorrect example 
              in the AMOS Administration Guide.  Discussion about setting 
              policy on the /unix file.

    APAR IY50239
    Symptom:  DOCUMENTATION APAR (See 4.1-PDO-FP04.README).  Ordering of 
              PAM modules can affect login policy. Discussion about ordering 
              of PAM modules is found in the AMOS 4.1 Problem Determination 
              Guide.  

    APAR IY50260
    Symptom:  pdosd core file created when AMOS runs a strlen on a null 
              pointer.  Analysis of the core shows oss_uid_to_name() calls 
              strncmp().

    APAR IY51192
    Symptom:  DOCUMENTATION APAR (See 4.1-PDO-FP04.README).  Incorrect 
              statement made in the AMOS Adminstration Guide.  No Secure-Files 
              are defined by default in the TCB.

    APAR IY51885
    Symptom:  DOCUMENTATION APAR (See 4.1-PDO-FP04.README).  
              The 4.1-PDO-FP02, IY39355: "Denials occur in audit logs when 
              logging in" section.   The Access-Restriction attribute on the 
              osseal-var-login acl should be deleted first.

    APAR IY52081 (Originating APAR: IY46998)
    Symptom:  pdostecd terminates abnormally.  When the subroutine 
              gethostbyname fails, an error is logged and the PDOSTECD daemon 
              is terminated.  The failure of the subroutine gethostbyname 
              indicates a problem with the name services.  PDOSTECD can 
              continue to function without the name services running correctly.
              The new code will log a "Unable to determine network host entry"
              to /var/pdos/pdostecd/pdostecd.log for each occurrence of the 
              failure. 

    APAR IY52083 (Originating APAR IY45392)
    Symptom: AIX Only.  With xmalloc debug enabled, system crashes due to 
             write of memory that has been freed.  A crash evaluation may 
             show that kpcf_asyncLUReq is the culprit.     
                  
    APAR IY52084 (Originating APAR IY51334)
    Symptom: More than five logins in time span less than a second will 
             cause some logins to fail. (example:  using multiple rcp commands 
             from a remote system to a system running remshd and AMOS)


Problems Fixed in 4.1-PDO-0003LA:

    Note:  4.1-PDO-0003LA is a limited availability interim release fixpack.
           Since 4.1-PDO-FP04 is available, support for 4.1-PDO-0003LA has 
           been withdrawn.   All APARs fixed in 4.1-PDO-0003LA are included
           in 4.1-PDO-FP04.


Problems Fixed in 4.1-PDO-FP02:


    APAR IY42026 
    Symptom: Linux only.   Logging in using some login programs  
             causes the pdoswhoami command to report the root user as 
             the effective user id for non-root accounts.
             
    APAR IY42724            
    Symptom:  DOCUMENTATION APAR.  AMOS supports both 32 and 64 bit versions
              of AIX 5.1.  AMOS supports both 32 and 64 bit versions of AIX
              5.2 with 4.1-PDO-FP01 or higher installed.

    APAR IY43368
    Symptom:  The trace_exec audit level produces an very large amount of 
              audit data. All that is required is trace_exec auditing for
              root and for surrogate operations.  New global audit levels
              have been introduced to solve this problem.  See discussion  
              below for more details.

    APAR IY44625 (Originating APAR: IY39355)
    Symptom:  Incorrect denials are showing up due to ACL permissions during
              login.  A procedure is documented for correcting this problem at
              the end of this document.


    APAR IY45391
    Symptom:  DOCUMENTATION APAR.  IY38923 was not documented as fixed in
              4.1-PDO-FP01.README.  IY38923 was fixed in fixpack 4.1-PDO-FP01.
              The APAR is documented in this README under the "Problems Fixed
              in 4.1-PDO-FP01" section. 

             
    APAR IY45765 (Originating APAR: IY36094)
    Symptom:  HPUX only: When native TCB is set and the
              Sudo-Password-Invoker attribute is set on a sudo object, a
              failure occurs when the user's UNIX password is entered.
                                                                           
    APAR IY45771 (Originating APAR: IY42935)
    Symptom:  pdosd fails to process messages from the kernel, causing pdosd to
              grow as messages queue.

              
    APAR IY45772 (Originating APAR: IY42308)
    Symptom:  DOCUMENTATION APAR (See below).  Startup order of AMOS can
              affect network policy enforcement.
              
              
    APAR IY45853
    Symptom:  AMOS does not support some later versions of Linux Kernels  See
              4.1-PDO-FP02.README for a complete listing of supported Linux 
              Kernels.

 
    APAR IY45856
    Symptom:  There is no method to attaching acls on files and 
              directories located in the root directory.  See 
              discussion below for more details.            


Problems Fixed in 4.1-PDO-FP01:

    APAR IY42027 (Originating APAR: IY30341)
    Symptom:  HPUX Only. When user issues a login command from a 
              session, the login acts as an su.  All access 
              decisions are made based on the user before the login.
                
    APAR IY42028 (Originating APAR: IY34482)
    Symptom:  When policy is defined on file resources residing in an 
              automounted directory and the remote file resource is
              unavailable, AMOS attempts to lookup the file resource and 
              waits for a significant amount of time before timing-out.     
              The system appears to hang.  

    APAR IY42029 (Originating APAR: IY37459)
    Symptom:  When the DNS does not respond in a timely fashion, the
              system will appear to hang upon waiting for credentials.

    APAR IY42030 (Originating APAR: IY37539)
    Symptom:  pdossudo command does not pick-up correct PATH variable.

    APAR IY38718
    Symptom:  HPUX and Solaris:  When an application is attempting to kill
              many java processes on a multiprocessor system, the system 
              response will appear to become sluggish and eventually hang.

    APAR IY38733
    Symptom:  Solaris only: On multiprocessor systems:  A mutex was unlocked
              prematurely in nct_vfork32_pre and nct_fork132_pre resulting in
              a system crash.

    APAR IY42031 (Originating APAR: IY38734)
    Symptom:  Solaris Multiprocessor systems only:  A system crash can occur 
              when killing processes in pidToPgrp 

    APAR IY42032 (Originating APAR: IY38779)
    Symptom:  Solaris only:  A /reconfigure file is created upon loading of
              the AMOS kernel drivers.  rc.kosseal has been changed to 
              recognize when AMOS creates the /reconfigure file and deletes it.

    APAR IY38783
    Symptom:  Solaris only:  On multiprocessor systems.  An invalid address 
              was referenced by makeFidChain resulting in a system crash.

    APAR IY38784
    Symptom:  On multiprocessor systems.  An invalid address was referenced
              by kenv_procCloseFd resulting in a system crash.

    APAR IY38923
    Symptom:  When a user known to the local operating system attempts to 
              login and is rejected by the local operating system, lpm audits 
              the event with the Audit View = Permit and the Audit 
              Qualifier = 'Login denied by native authentication method.'.
              The Audit View should be Deny. 

    APAR IY39982
    Symptom:  DOCUMENTATION APAR (See below).  HPUX11i only.  When installing 
              AMOS on HPUX11i with superceding HPUX patches PHCO_24400 and 
              PHCO_24402, installation fails in the checkinstall script.

    APAR IY42033 (Originating APAR: IY38785)
    Symptom:  When an AMOS audit log becomes corrupted, pdosaudview doesn't 
              attempt to continue processing remaining audit logs.

    APAR IY40469
    Symptom:  When a process is started by a relative symlink, the process 
              cannot be killed unless you are exempt from policy enforcement. 
              See IY41309.

    APAR IY41309
    Symptom:  DOCUMENTATION APAR (See below).  When killing a     
              process after the starting executable has been moved or 
              deleted, the process cannot be killed.  Instructions are
              given to work around this issue. 

    APAR IY41494
    Symptom:  DOCUMENTATION APAR (See below).  Uninstall instructions
              could remove unintended software.

    APAR IY41506
    Symptom:  DOCUMENTATION APAR (See below).  Audit level information on 
              page 88 of AMOS Administration Guide is incorrect. 



    
Platforms:
    AIX 4.3.3, 5.1 and 5.2
    HP-UX 11 and 11i
    Solaris 2.7, 2.8 and 2.9
    Red Hat Linux (x86) 7.1, 7.2 and 7.3
    SuSE Linux (x86) 7.3, 8.0
    Red Hat Linux (x86) Advanced Server (RHAS) 2.1
    SuSE Linux (x86) Enterprise Server (SLES) 7
    Red Hat Linux (s390 and zSeries) 7.2
    SuSE Linux (s390 and zSeries) SLES7 

    Please refer to the AMOS 4.1 release notes to obtain further information
    about supported platforms.
 
 
Fixpacks superseded by this fixpack:  None

Dependencies:

    Access Manager for Operating Systems 4.1.0.0 (Gold Version)


Fixpack Contents:

    - This README file
    - 4.1-PDO-FP04.aix.tar.Z  Contains the .bff file.
    - 4.1-PDO-FP04.solaris.tar.Z Contains the PDOSRTE000410-04
          directory structure.
    - 4.1-PDO-FP04.i386.linux.tar.Z  Contains the Intel-based .rpm file.
    - 4.1-PDO-FP04.s390.linux.tar.Z  Contains the zSeries-based .rpm file.
    - 4.1-PDO-FP04.hpux.tar.Z  Contains the .depot file


Applying the Fixpack:

    Read the RELEASE NOTES before applying the fixpack.  

    AMOS 4.1 Native fixpack installation instructions
    -----------------------------------------------

      1. Log in to the workstation as root. 

      2. Extract the archive into a temporary directory.  For the
         purpose of this README, assume that the symbol $PATCH
         points to this temporary directory.  Assume that the symbol
         $OS represents the operating system (aix, linux, solaris or hpux)

         # cd $PATCH 
         # uncompress 4.1-PDO-FP04.$OS.tar.Z
         # tar -xvf 4.1-PDO-FP04.$OS.tar

      3. Stop the Access Manager for Operating Systems processes:
             rc.osseal stop

      4. Recommendation:  Configure AMOS with autostart off

         #pdoscfg -autostart off

      5. At the command prompt, enter the following: 

         On AIX:

            installp -ac -d $PATCH PDOS.rte

         On HPUX:

            swinstall -s $PATCH/PDOSRTE000410-04.depot PDOSrte 

         On Solaris:

            cd $PATCH
            patchadd PDOSRTE000410-04

         On Linux (x86):

            cd $PATCH
            rpm -F PDOSrte-PDOSruntime-4.1.0-4.i386.rpm


         On Linux (s390):

            cd $PATCH
            rpm -F PDOSrte-PDOSruntime-4.1.0-4.s390.rpm

      6. Reboot your system.  This fixpack contains kernel driver 
         updates which will not take effect until your system has
         been restarted.

 
 
 Uninstall Instructions:


    Unix (logged in as root)
    ------------------------

    1.  Stop the Access Manager for Operating Systems processes:

        # rc.osseal stop

    2.  Unconfigure AMOS
        # pdosucfg

    3.  Follow the uninstall procedure for your operating system:

        - AIX
        # installp -u PDOS.rte

        - Solaris
        # pkgrm PDOSrte

        - HPUX
        # swremove PDOSrte,r=4.1.0.4   
        /* if 4.1-PDO-FP03 is installed */
        # swremove PDOSrte,r=4.1.0.3
        /* if 4.1-PDO-FP02 is installed */
        # swremove PDOSrte,r=4.1.0.2
        /* if 4.1-PDO-FP01 is installed */
        # swremove PDOSrte,4=4.1.0.1 
        # swremove PDOSrte,r=4.1.0.0

        - Linux
        # rpm -e PDOSrte-PDOSruntime-4.1.0-4



Additional Installation Instructions:

    Release Notes
    -------------
    For the latest information on the product, please read the
    Release Notes for Access Manager for Operating Systems 4.1 
    found under the following URL:

    http://publib.boulder.ibm.com/tividd/td/
         AccessManagerforOperatingSystems4.1.html2


Known Issues and Workarounds: 


    Retrusting AMOS when the pdosobjsig command becomes untrusted
    -------------------------------------------------------------
    It is possible that you may have untrusted any objects defined 
    in the TCB.  

         -  Open two sessions. Ensure that both sessions are opened 
            by users with administrative priviledges.

         -  In one session, restart AMOS
            # rc.osseal start

         -  Run "pdosobjsig -l untrusted"

         -  If pdosobjsig returns with an 'unable to execute' error 
            message, use your second session to kill pdosd.
            # ps -ef | grep pdosd <= remember the PID
            # kill <PID of pdosd>

         -  Run 'pdosobjsig -l untrusted'.  Review the files that are 
            untrusted.

         -  Retrust your untrusted TCB objects.
            # pdosobjsig -S trusted

         -  start pdosd
            # rc.osseal start


    Using pdosexempt when unable to kill a process (IY41309)
    --------------------------------------------------------
    The pdosexempt utility enables an administrative user to exempt a 
    process from policy enforcement. By running pdosexempt, the file 
    information lookup does not occur and the process can be killed.

    Example:
    a program exists called /bin/racecar.
    # /bin/racecar &           <= run racecar
    [1] 6543                   <= note the process ID
    # rm /bin/racecar          <= remove the executable
    # kill 6543                <= kill the process
    process 6543:  not found   <= error


    Open a shell.  Login as an AMOS runtime administrative user.  From
    the shell, run the following commands:

    # ps -ef | grep grep        <= search for your current shell process
    harry  3892 10382  1 08:24:43 pts/3    0:00 grep grep

    ==> Note:  process 3892 is the process that is running grep.
    Process 10382 is the parent, which is your current shell.


    # pdosexempt -i 10382      <= exempt the parent process of grep
    Process 10382 and any future children are now exempt from policy.
    # kill 6543                <= kill the /bin/racecar process
    #                          <= process killed

                                                                               
    Denials occur in audit logs when logging in (IY39355,IY51885)
    -------------------------------------------------------------

    Note:  IY51885 corrects the procedure for changing policy in this 
    section.  When applying attributes an acl, the former Access-Restriction
    attribute is not replaced.  The new attribute is added, in addition to,
    the list.

    Denials can occur in the audit log when running the login program.
    A change in policy fixes this problem.

    The following example is an audit event that should not be denied.

    Timestamp                   Tue Jan 14 09:01:13 2003
    Audit Event                 An authorization decision was made.
    Audit View                  Deny
    Audit Reason                Global Audit
    Audit Resource Type         File
    Accessor Name               harry
    Accessor Effective Name     root
    Audit Action                Check Access
    Audit Permissions           readdir
    Audit Qualifier             Checking Access-Restrictions associated
                                with resource access control policy.
                                Policy Branch name orion27
                                                                               
    Protected Object Name       File/var/pdos/login
    System Resource Name        /var/pdos/login/
    Accessor Process ID         711
    Running Program Protected Name       /usr/bin/login
    Running Program System Resource Name /usr/bin/login
    Audit Outcome               Success
    Audit Uniqifier             2
                                                                               
                                                                               
    Use the following instructions to fix the incorrect audit log denials

    1)  Run pdadmin
    pdadmin -a <pdadmin admin user ID> -p <password>

    2) Modify the acl osseal-var-lpm
    pdadmin> acl modify osseal-var-lpm set any-other T[OSSEAL]Ndlorw
    pdadmin> acl modify osseal-var-lpm set unauthenticated T[OSSEAL]Ndlorw

    3) List the access restriction attribute.  Write down what is listed.
    pdadmin acl show osseal-var-lpm attribute Access-Restrictions

    4) Delete the exisiting access restriction on the acl osseal-var-lpm
    pdadmin> acl modify osseal-var-lpm delete Access-Restrictions

    5) Modify access restrictions on the acl osseal-var-lpm.  Add /usr/bin/login
       and /usr/sbin/login to your what was listed in step 3. 
    This is an example:
    pdadmin> acl modify osseal-var-lpm set attribute Access-Restrictions \
        "any-other:Ndlorw:/opt/pdos/bin/pdos_pwdrestrict /usr/bin/passwd \
        /usr/bin/login /usr/sbin/login"
    pdadmin> acl modify osseal-var-lpm set attribute Access-Restrictions \
        "unauthenticated:Ndlorw:/opt/pdos/bin/pdos_pwdrestrict           \
         /usr/bin/passwd /usr/bin/login /usr/sbin/login"

    6) pdadmin> quit

    7) Take steps dependent on your Access Manager for e-business setup
       to propagate the Access Manager database.


    Errors in AMOS 4.1 Release Notes, Chapter 2.  "Supported Operating 
    System Levels and Required Patches" Section (IY39981)
    ---------------------------------------------------------------------
    HPUX 11 and 11.11 (11i) both show "No specific patches at the time";
    this information is incorrect.

        HPUX 11 requires
            XSWGR1100 General Release Patches
            PHKL_25475 PM Cumulative Patch 

        HPUX 11i requires
            PHCO_24402 cumulative header file patch
            PHCO_24400 libc cumulative patch


    Corrections for required Sun Solaris OS 2.8 (32-bit and 64-bit) patches

        Patch 108434-05 is required (not 109434-05)
        IY29109 should be removed. This is not a Solaris patch number


    Installation failure on HPUX 11.11 (11i) (IY39982)
    --------------------------------------------------
    Installation of AMOS 4.1 on HPUX 11.11 requires operating system patches
    PHCO_24400 and PHCO_24402.  But if patches which supercedes the required
    patches have been installed then the AMOS 4.1 installation fails.

    The workaround replaces the HPUX 11.11 /usr/sbin/swlist executable with a
    script which allows the installation to continue. Detail steps follow.

    Workaround:

    1. Before AMOS installation.
    2. Login to HP system as root.
    3. cd /tmp
    4. Create following script named "swlist.fake"

    #!/bin/sh
    if [ $# = 1 ] && [  $1 = "PHCO_24400" ]
    then
         exit 0
    fi

    if [ $# = 1 ] && [  $1 = "PHCO_24402" ]
    then
         exit 0
    fi

    exec swlist.real $*
    exit $?

    5. chown root:bin swlist.fake
    6. chmod 4555 swlist.fake
    7. cd /usr/sbin
    8. ls -l swlist (Note: The permissions and ownership of /tmp/swlist.fake 
       must match the permissions and ownership of /usr/sbin/swlist)
    9. mv swlist swlist.real
    10. cp /tmp/swlist.fake swlist
    11. Perform AMOS installation.
    12. After AMOS installation, cd /usr/sbin
    13. rm swlist
    14. mv swlist.real swlist


    Uninstall instructions could remove unintended software (IY41492)
    -----------------------------------------------------------------
    In the "AMOS Installation Guide", "Chapter 8. Uninstalling", section 
    "Uninstalling Associated Products", "Uninstalling on AIX" subsection. 
    (Page 61 in the English language version)

    The documented steps show the installp -g option. The unintended 
    consequence of using installp -g with GSKit is the uninstallation of 
    products that use this level of GSKit. 

    ***Do not use the -g option.***


    Incorrect audit level information of the AMOS Administration Guide
    (IY41506)
    ------------------------------------------------------------------
    In the "AMOS Administration Guide", "Administrative Tasks" chapter, 
    section "Verifying Policy", subsection "Using Auditing to Verify Policy",
    sub-subsection "Setting and Querying the Resource Audit Level".

    The Administrator Guide indicates that the audit level in a POP can 
    be set to permit, deny, all or none.  ***AMOS only supports permit and 
    deny audit levels for per-resource level auditing.***


    Startup order of AMOS can affect network policy enforcement (IY42308)
    ---------------------------------------------------------------------
    If the AMOS kernel drivers loaded after an application, network policy
    may not be enforced on the application.  The AMOS kernel driver does not
    have a mechanism to discover previously loaded applications and their
    open communication sockets.  The workaround is to load AMOS prior to
    starting the application.


    Additional Linux kernels supported (IY45863)
    --------------------------------------------
    With fixpack 4.1-PDO-FP02 and higher, the following Linux kernels
    will be supported:

    RedHat Linux 7.1 (x86)
        shipped kernels: 
            kernel-2.4.2-2.i586.rpm
            kernel-2.4.2-2.i686.rpm
            kernel-smp-2.4.2-2.i586.rpm
            kernel-smp-2.4.2-2.i586.rpm
        updated kernels:
            kernel-2.4.9-31.i586.rpm
            kernel-2.4.9-31.i686.rpm
            kernel-smp-2.4.9-31.i586.rpm
            kernel-smp-2.4.9-31.i686.rpm
            kernel-2.4.9-34.i586.rpm
            kernel-2.4.9-34.i686.rpm
            kernel-smp-2.4.9-34.i586.rpm
            kernel-smp-2.4.9-34.i686.rpm

    RedHat Linux 7.2 (x86)
        shipped kernels:
            kernel-2.4.7-10.i686.rpm
            kernel-smp-2.4.7-10.i586.rpm
            kernel-smp-2.4.7-10.i686.rpm
        updated kernels:
            kernel-2.4.9-31.i586.rpm
            kernel-2.4.9-31.i686.rpm
            kernel-smp-2.4.9-31.i586.rpm
            kernel-smp-2.4.9-31.i686.rpm
            kernel-2.4.9-34.i586.rpm
            kernel-2.4.9-34.i686.rpm
            kernel-smp-2.4.9-34.i586.rpm
            kernel-smp-2.4.9-34.i686.rpm

    RedHat Linux 7.3 (x86)
        shipped kernels:
            kernel-2.4.18-3.i686.rpm
            kernel-smp-2.4.18-3.i586.rpm
        updated kernels:
            kernel-smp-2.4.18-3.i686.rpm
            kernel-2.4.18-10.i586.rpm
            kernel-2.4.18-10.i686.rpm
            kernel-smp-2.4.18-10.i5686.rpm

    RedHat Advanced Server 2.1 for x86
        shipped kernels: 
	    kernel-2.4.9-e.3.i686.rpm 
	    kernel-smp-2.4.9-e.3.i686.rpm
        updated kernels: 
            kernel-2.4.9-e.12.i686.rpm 
            kernel-smp-2.4.9-e.12.i686.rpm 
            kernel-2.4.9-e.16.i686.rpm 
            kernel-smp-2.4.9-e.16.i686.rpm

    RedHat Enterprise Linux AS/WS/ES 2.1 for x86
        shipped kernels:
            kernel-2.4.9-e.12.i686.rpm 
            kernel-smp-2.4.9-e.12.i686.rpm 
        updated kernels: 
            kernel-2.4.9-e.16.i686.rpm 
            kernel-smp-2.4.9-e.16.i686.rpm

    SuSE Linux 7.3 (x86)
        shipped kernels:
            k_deflt-2.4.10-12.i386.rpm
            k_smp-2.4.10-12.i386.rpm
        updated kernels:
            k_deflt-2.4.16-37.i386.rpm
            k_smp-2.4.16-38.i386.rpm

    SuSE Linux 8.0 (x86)
        shipped kernels:
            k_deflt-2.4.18-58.i386.rpm
            k_smp-2.4.18-57.i386.rpm

    SuSE SLES7 for x86
        shipped kernels:
            k_deflt.rpm (k_deflt-2.4.7-20) 
            k_smp.rpm (k_smp-2.4.7-19)
        updated kernels:
            k_deflt-20030324.rpm (k_deflt-2.4.18-262) 
            k_smp-20030324.rpm (k_smp-2.4.18-244)

    SuSE SLES7 for zSeries 31bit:
        shipped kernels:
            k_deflt-2.4.7-31.s390.rpm*
        updated kernels:
            k_deflt-20030221.rpm (k_deflt-2.4.7-77) 
            k_timer-20030221.rpm (k_timer-2.4.7-28)

    SuSE SLES7 for zSeries 64bit with 31bit compat:
        shipped kernels:
            k_deflt-2.4.17-21.s390.rpm
        updated kernels:
	    k_deflt-20030221.rpm (k_deflt-2.4.17-51) 
	    k_timer-20030221.rpm (k_timer-2.4.17-13)

    RedHat 7.2 for zSeries 31bit:
        shipped kernels:  
            kernel-2.4.9-37.s390.rpm
        updated kernels:
            kernel-2.4.9-38.s390.rpm



    Unless otherwise speicfied in a future 4.1 fixpack README, 
    no other linux kernels are supported.

    Note:  The SuSE kernel drivers listed above are followed by the
           output of "rpm -qa|grep k_ ".  When reporting a problem with
           a SuSE kernel driver, please report the output of the rpm command.


    New File Resource, RootDir, Provides the Ability to Protect the Root 
    Directory (/)  (IY45856)
    ------------------------------------------------------------------------
    Included in this fixpack is support for a new File resource name, 
    /OSSEAL/policy-branch/RootDir.  The RootDir resource name provides a way 
    to define access control policy to protect the root directory (/).    

    To ensure that authorization decisions can be made efficiently, Tivoli 
    Access Manager for Operating Systems assumes that permissive access 
    controls are attached at the /OSSEAL/policy-branch/File resource.  An 
    explicit ACL attached to the File object or higher is ignored for both 
    access to the file system root directory (/) and for the purposes of 
    inheritance.   This meant that access control policy could not be placed 
    on the root directory itself.  Policy could only be defined for the 
    contents of the root directory by explicitly defining policy under the 
    File resource for those files and directories residing in the root 
    directory that needed to be protected.  Introduction of the RootDir file 
    resource name allows access control policy to be defined to govern access 
    to the root directory and it's contents.  

    To define access control policy for the root directory (/), create the 
    object /OSSEAL/policy-branch/RootDir and attach access control policy 
    (ACLs and POPs).  ACLs and POPs attached to the "RootDir" object apply to 
    the root directory itself and files and directories residing in the root 
    directory that are not governed by policy defined under the File resource.
    Policy defined under the File resource takes precedence over the policy 
    defined for the RootDir object.   

    When defining access control policy for the root directory, the following 
    should be considered:
    ·  The policy governing the RootDir object applies both to the root 
       directory itself and it's immediate contents.  Policy governing RootDir 
       applies to all files and directories residing in the root directory 
       that are not governed by policy defined under the File resource. Defining
       policy that is too restrictive may prevent users and applications
       from accessing commonly used directories, such as /tmp and /home.

    ·  No objects should be defined under the "RootDir" object.  An error 
       will be logged in /var/pdos/log/msg__pdosd.log if an object is defined 
       under the /OSSEAL/policy-branch/RootDir object.

    ·  Unlike objects defined as File resources, ACLs and POPs attached to the 
       RootDir object are NOT inherited.  

    Example setup of access control policy for the root directory (/):

    The security administrator wants to protect the root directory and 
    it's contents that are not governed by policy defined under the File 
    resource.  The administrator wants to define policy that gives all 
    unauthenticated and authenticated users (any-other) read-only access to 
    files and directories that reside in the root directory and allows them to 
    change directory into directories that reside in the root directory, but 
    doesn't allow them to create files or modify the contents of any files and 
    directories residing in the root directory. The policy should also give 
    members of the admin group full access to the root directory and the files 
    and directories residing in the root directory.  In addition, all users 
    should have full access to the /tmp directory and it's contents.

    For this example, the branch name is called "system":

      pdadmin> object create /OSSEAL/system/RootDir "root dir" 0 \
               ispolicyattachable yes
      pdadmin> acl create rootdir_acl
      pdadmin> acl modify rootdir_acl set unauthenticated T[OSSEAL]Dlr
      pdadmin> acl modify rootdir_acl set any-other T[OSSEAL]Dlr
      pdadmin> acl modify rootdir_acl set group admin T[OSSEAL]DKNRUdloprwx
      pdadmin> acl attach  /OSSEAL/system/RootDir rootdir_acl
      pdadmin> object create /OSSEAL/system/File/tmp "tmp directory" 0 \
               ispolicyattachable yes
      pdadmin> acl create tmpdir_acl
      pdadmin> acl modify tmpdir_acl set unauthenticated T[OSSEAL]DNRUdloprwx 
      pdadmin> acl modify tmpdir_acl set any-other T[OSSEAL]DNRUdloprwx
      pdadmin> acl attach /OSSEAL/system/File/tmp tmpdir_acl



    New global audit levels:  trace_exec_l and trace_exec_root (IY43368)
    --------------------------------------------------------------------
    Enabling the trace_exec global audit level causes the AMOS 
    kernel code to track program invocations initiated by exec() 
    that occur in processes that descend from a login event that 
    was detected by Tivoli Access Manager for Operating Systems.  
    Depending upon the activity on the box, turning on the trace_exec 
    global audit level can generate a large amount of auditing data that 
    is difficult to manage.  This level of tracking of exec() activity may
    not be required.   New global audit levels, trace_exec_l and 
    trace_exec_root, have been added to help limit the amount of TraceExec 
    data that is generated.   

    When the trace_exec_l global audit level is enabled, and the 
    trace_exec audit level is not enabled, TraceExec audit data is only 
    generated for exec() activity when the accessing user's accessor identity 
    is different then their effective user identity (this typically happens 
    when a user surrogates to another user).   Use of the trace_exec_l 
    instead of trace_exec eliminates TraceExec audit data being generated 
    when the accessing user's accessor identity is the same as their effective 
    user identity.  
 
    When the trace_exec_root global audit level is enabled, TraceExec audit 
    data is generated for exec() activity when the accessing user's accessor 
    identity is the root user.  

    Using both the trace_exec_root and trace_exec_l global audit levels will 
    cause TraceExec audit data to only get generated for program invocations 
    initiated by exec() that occur in processes that descend from a login event 
    that was detected by Tivoli Access Manager for Operating Systems and 
    when the accessing user's accessor identity is either the root user or the 
    accessor identity is different then the effective user identity.

    The pdoscfg and pdosctl commands will now recognize these two new 
    audit levels.  The pdoscfg command is used to modify the configuration 
    files.  These modifications take effect the next time Tivoli Access Manager 
    for Operating Systems is stopped and restarted.  The pdosctl command 
    dynamically changes Tivoli Access Manager for Operating Systems while 
    it is running.  The changes take effect immediately and are not persistent 
    when you restart.

    To modify the configuration and have the modification take effect 
    the next time Tivoli Access Manager for Operating Systems is started 
    on the system, use the pdoscfg command -audit_level parameter.  This 
    resets the current audit level in the configuration files so all required 
    audit levels must be specified:

    # pdoscfg -audit_level trace_exec_l,trace_exec_root,  \
      <other audit levels used in the environment>

      where <other audit levels used in the environment> are any of the 
      other supported global audit levels such as admin, loginpermit, 
      logindeny, permit, deny or trace_file.

    To dynamically change the Tivoli Access Manager for Operating Systems
    current runtime, use the pdosctl -a to turn on the new levels.  Use 
    of the -a option enables additional audit levels and does not reset 
    the current audit levels, if trace_exec is enabled, it can be turned off 
    when the new levels are enabled:

    # pdosctl -a trace_exec_l:on  -a trace_exec_root: on  -a trace_exec:off



    Incorrect patch recommendation for HPUX 11i in release notes (IY46821)
    ----------------------------------------------------------------------
    On page 14 of the AMOS Release Notes, the "Recommended Path for HP-UX
    11.11 Systems" section.  A recommendation to install fix PHNE_25064 is
    incorrect.  The correct HP-UX 11.11 patch is PHNE_25084.


   
    Incorrect patch requirements for Solaris 2.7 (IY47162)
    ------------------------------------------------------ 
    On page 5 of the AMOS Release Notes, the "Supported Operating System 
    Levels and Required Patches" section.  The required patch list for 
    Solaris is missing a solaris patch.  Solaris fix 106980-13 or greater 
    is required.


                                                                                
    Incorrect policy example in AMOS Admin Guide (IY50082)                      
    -----------------------------------------------------                       
    In the AMOS 4.1 Administration Guide, "Policy" Chapter, "Protected 
    System Resources" section, "File Policy" then "File Resources" 
    subsections. (English language version, physical page 19).                 
 
    A bulleted point below Table 9 says:  "The Kill(K) permission can be        
    applied to the special File resource /OSSEAL/policy-branch/unix to control  
    the ability to shutdown or reboot the system"  The File resource is         
    incorrect.                                                                  
                                                                                
    *** The File resource should be /OSSEAL/policy-branch/File/unix. ***        
                                                                                
    Further, special consideration should be taken when setting this policy.    
    On some platforms, applying this policy prevents you from killing the OS    
    process, but it does not control who can execute halt, stop, shutdown,      
    reboot,  etc.  The machine may go down to some state where it becomes       
    unusable.  Policy in general should be applied to the before mentioned      
    commands. Applying policy to File/unix is will stop someone from            
    trying to kill proc id 0 or 1.                                              



    Ordering of PAM Modules can affect login policy.  (IY50239)
    -----------------------------------------------------------
    The AMOS Problem Determination Guide discusses ordering of entries in the  
    /etc/pam.conf file.  It is important to note the differences in using 
    sufficient vs. required in pam.conf.  Also, AMOS does not remove entries
    from the pam.conf when uninstalled.

    This discussion is found in the AMOS Problem Determination Guide, 
    "Chapter 5. Troubleshooting Login Activty and Password Management Policy",
    Section "PAM Configuration Conflicts".  (English Language version, physical
    page 36).  



    AMOS Administration Guide incorrect statement about Secure-Files (IY51192)  
    -------------------------------------------------------------------------- 
    In the AMOS 4.1 Administration Guide, "Policy" Chapter, "Protected System   
    Resources" section, "File Policy" then "Trusted Computing Base Resource"   
    subsections.  (English language version, physical page 26). 
                                                                               
    Under the "Secure-Files" section, the second sentences states:             
                                                                               
    "Tivoli Policy Director for Operating Systems defines some Tivoli Policy   
    Director for Operating Systems files as Secure-Files when initially         
    configured."                                                               
                                                                               
    This sentence is incorrect.  There are no files on any AMOS platform that  
    is defined in the TCB/Secure-Files section during configuration.               
