by Paul Taffel, VESOFT
        Presented at SCRUG (Southern California Regional User Group)
                     1993 Meeting, Burbank, CA, USA


  This paper is NOT intended to cover all UNIX security issues, rather I'll
  try to highlight some of the significant issues that need to be addressed
  when trying to secure your system, and then comment on peculiarities of
  HP's UNIX implementation.  There are enough areas where HP-UX differs from
  other UNIX implementations in the areas of security to warrant this

  In general, do NOT assume that if you've closed the loopholes described
  here, that your system is secure.  It won't be.  If you are responsible
  for controlling access to your UNIX system, you should obtain some of the
  excellent UNIX security books available (see references section), and
  preferably both obtain and regularly use a security auditing tool.

  The impression that most users will come away with after looking at the
  material contained in any of the reference documents is that effectively
  controlling access to a UNIX system could turn into a full-time task.

  Unfortunately, even if you don't aim to master the intricacies of UNIX
  security, a thorough understanding is highly recommended to allow you to
  effectively use the available tools in keeping your system secure.

  Note:  References to security in this paper refer to standard current
         releases of HP-UX, versions 7 through 9, as implemented on HP's
         series 700 and 800 machines.

         This paper does not apply to the special 'B1' security level UNIX
         release: HP-UX BLS.

UNIX Security Concerns

  Security concerns can be divided into the following topics:

  - User and Group related security concerns.
    Including login security, weak passwords, etc.

  - File system related security problems.

  - Logfile analysis

  - Network related security problems

  I'll point out HP-specific concerns with each of these topics, starting
  with brief introductions to each topic.

User and Group Related Security Concerns

  Login security

    UNIX systems control system access and associated privileges using user
    accounts.  A user account is defined by making entries in /etc/passwd,
    each entry defines the following account attributes:

    - login name
    - encrypted password, and optional password aging data
    - numerical user ID
    - numerical group ID
    - comment
    - home directory
    - default shell

    The user ID number is the primary mechanism used to separate different
    users from each other, and allows file ownership to be traced back to
    the user that created the file.

    Although different users may be defined with the same user ID number, it
    will not be possible to distinguish between such users once they have
    logged in.  As this makes prevents effective auditing of security
    violations, shared user IDs should not be allowed.

    The system grants special (superuser) capabilities to any users defined
    with a zero user ID number.  UNIX contains no mechanism for granting
    subsets of superuser capabilities (comparable with MPE's AM, PM, OP
    capabilities), hence superuser capability is an all-or-nothing affair.
    Superusers may essentially do or access anything on the system, this
    is therefore the 'holy grail' of hackers everywhere.

    The Group ID number is used to define a user's primary group membership.
    Although this is primarily used as a mechanism to allow file access to
    be shared between different users requiring access to the same files,
    group ownership may also confer (on HP-UX) some additional capabilities.

    UNIX systems traditionally define 'pseudo' account entries in the
    /etc/passwd file, such as user entries for date, who, sync and tty.
    HP-UX has moved towards eliminating logon access to these commands by
    removing these entries from the password file, this has the benefit of
    only allowing access to these commands to users who are in possession of
    valid account IDs and passwords.  Alternatively, such administrative
    accounts should be setup with locked password fields to prevent their
    being used for interactive logins.

  User Groups

  Anyone trying to figure out exactly how HP-UX implements group security
  is in for a confusing time, here follows is what we managed to figure out.

  Be warned, this material is not intended for those of a sensitive

  Traditionally where group membership is concerned, UNIX implementations
  fall into two main camps having the following features in common:

  - every group has a unique name and Group ID number
  - all groups are defined in the /etc/group file, containing the following
    fields for every group entry:

    - group name
    - optional encrypted group password
    - group ID number
    - list of users who are group members, separated by ','s

  - every user belongs to a primary group, as defined in the /etc/passwd
    file, but may also be assigned membership of other (secondary) groups
    within the /etc/group file.
  - primary group membership is used when creating new files.  The user's
    primary group ID is assigned to any files built, and becomes the file's
  - both primary and secondary group IDs are used when deciding what access
    rights the user has to any particular file.
  - Note that a user might only be assigned group membership by reason of
    their /etc/passwd entry, this (primary) group membership does not have
    to be explicitly defined in the /etc/group file, although it should be.

  At this stage, the two UNIX camps diverge along the following lines:

  - System V UNIX only allows a user to reside in a single group at any
    given time.  The newgrp(1) command may be used at any time to switch
    the user's primary group ID to that of another group.

    Users are able to switch into two classes of groups:

    1) groups that they are defined as members of via the /etc/group file

    2) groups that they are not members of, but only if the group has a
       password defined in the /etc/group file, and the user can supply it.

  - BSD derived UNIX systems allow a user to be a member of more than one
    group at the same time.  When a user logs in, they are assigned primary
    group membership as defined in the /etc/passwd file, as well as
    secondary membership of all groups in the /etc/group file where they are
    defined as members.

    The newgrp command serves very little (if any) purpose in BSD UNIX, and
    is apparently omitted in many implementations.

  - HP-UX conforms to the BSD-system, with the following peculiarities:

    - each process has a list of up to 20 (typically) groups to which it
      may belong at the same time.

    - processes are allowed to access files if any of the groups that they
      are a member of is allowed access (see section on ACL below).

    - the newgrp(1) command may still be used at any time to switch the
      users's primary group ID to that of another group.  As the user is
      already a member of all groups to which they are assigned membership,
      the command serves only to allow them to become members of groups that
      they are not members of, but only if the group password is defined and
      the user supplies it.

    - HP-UX introduces one further complication: it makes use of the file
      /etc/logingroup.  If this file exists, it defines the initial list of
      groups that a user is to assigned membership of.  In other words, it
      defines a list of groups whose files a user should be allowed access
      to without having to use the chgrp command.

      File /etc/logingroup has an identical structure to that of /etc/group,
      although the only significant fields are the following:

      - group name
      - list of users who are group members, separated by ','s

      The structure is identical to /etc/group so that the two files may be
      linked together for simplicity.

      Any of the following scenarios may occur:

      1) /etc/logingroup missing or empty.

         Default group access list is empty, only group ID is the primary
         group defined in /etc/passwd.  Use newgrp command to gain access
         to any secondary groups.

      2) /etc/logingroup linked to /etc/group.

         Default group access list is the entire list of available
         secondary group IDs defined in /etc/group.  The newgrp command is
         only useful for gaining access to passworded groups that the user
         is not defined as a member of.

      3) /etc/logingroup contains a subset of the /etc/group data.

         User is granted group membership to a subset of the available
         groups.  The newgrp command may be used to access secondary groups
         not defined in /etc/logingroup.

      File /etc/logingroup should not contain any group IDs which are not
      also defined in /etc/group.  If the group is defined within /etc/group
      but not assigned to the user, then membership will be granted.  If the
      group is not defined at all within /etc/group, then membership is
      still granted.  As this behavior is not documented, do not rely on
      it remaining unchanged in future releases.

    - HP-UX documentation claims that /etc/logingroup is only available
      on Series 800 machines (reference #10, page 5-7).  This is incorrect,
      it works fine on all series 700 and 800 machines.

    - HP-UX documentation warns that no tools exists to ensure that entries
      in files /etc/passwd, /etc/group and /etc/logingroup are compatible.

      We recommend careful cross checking, and using the pwck command to
      scan the default password file for inconsistencies, and the grpck
      command to check the group file.

    - HP-UX documentation (the man page for initgroups) contains the
      following somewhat plaintive comment:

        WARNINGS:  On many systems, no one seems to keep /etc/logingroup
                   up to date.

    - a group may have up to 200 users associated with it.

  Group Passwords

  HP-UX shares the following feature with all other UNIX implementations:
  Groups may be assigned passwords if desired.  All security references
  consider this to be a bad idea for the following reasons:

  - If group passwords are defined (the second field in file /etc/group),
    then users who are not members of the group, but who know the group
    password, will be able to use the newgrp(1) command to change their
    group identification to this group.  If no password is defined (or if
    the password field is locked), then no user will be able to use the
    system newgrp(1) command to change their identification to this group.

    As group passwords are by nature shared, and as this approach to
    security is very difficult to enforce, we strongly recommend that group
    passwords are not used, and that any existing definitions be removed.

  - note that even if a user is assigned secondary group membership of a
    group, if they use newgrp to change their primary group ID to the group,
    they'll still be asked the group password, if one is defined.

  - world-read access must be available to /etc/group, and no equivalent
    of /.secure/etc/passwd is available to shield the encrypted passwords
    from curious hackers.

  In addition to this list, HP-UX documentation contains the following

  - no tool exists for setting group passwords in /etc/group, hence you'd
    have to figure out the encrypted value of whatever password you're
    using, and edit the file manually to add it.  Some UNIX implementations
    have a gpasswd command that allows group passwords to be manipulated
    more easily, but not HP-UX.

  If this isn't enough, the man page for newgrp warns that support for group
  passwords may be omitted from future releases of HP-UX, further reason to
  steer well away from their use.

  Listing Group Ownership

  If you want to report the group membership of a particular user, the id
  command can be used to report on the default group membership after login
  (regardless of if the user is currently logged in or not).  The groups
  command may also be used to determine exactly how group membership is
  conferred on any user.

  The following forms of the groups command are allowed:

  - groups -p user

    shows group ownership granted via /etc/passwd file

  - groups -g user

    shows group ownership granted via /etc/group file

  - groups -l user

    shows group ownership granted via /etc/logingroup file

  - groups user

    ORs together all of the above output.

  Note that reversing the order of parameters, and specifying something of
  the form 'groups user -p' will not generate any error, and will not work
  as expected.  In this case, the trailing parameter is simply ignored.

  Login Security Weaknesses

    A major weakness of UNIX security systems (as discussed in reference #5)
    is the world-readable nature of the system password file /etc/passwd.

    Brute-force password cracking programs are widely available that allow
    cracking of many passwords typically in use.  Allowing network-connected
    users to upload copies of user's encrypted passwords allows them to
    devote extensive resources to cracking the passwords on a remote system,
    away from prying eyes.

    The shadow password file /.secure/etc/passwd contains encrypted user
    passwords, but is secured to prevent user read access.

    The shadow password file contains the following fields on HP-UX:

    - logon name
    - encrypted password, and optional password aging data
    - numerical Audit ID
    - audit flag

    Passwords defined in /.secure/etc/passwd take precedence over those in
    /etc/passwd, even if the file doesn't exist!

    The presence of directory /.secure is actually the indication that a
    system has been converted to 'trusted' system status, even if the
    directory is empty.  There is a slightly unfortunate aspect to this
    behavior: if you build the directory manually, but neglect to construct
    a shadow password file within it, you will be locked out of the system.

  Trusted System Status

    The HP-supplied System Administration Manager (SAM) is used to convert
    an HP-UX system to 'trusted' status.

    The following steps are performed by SAM during the conversion process:

    - /etc/passwd file is copied to /etc/passwd.old.sav backup file

    - passwords are copied from /etc/passwd to /.secure/etc/passwd.  This
      new file is created without world read access.

    - encrypted passwords in the original file are replaced with '*'.

    - Audit ID is created for each user

    - the audit flag is set on for all users'

    - at, batch and crontab files are converted to use Audit ID.

    Notes: If you're converting to trusted system status, don't leave behind
           the /etc/passwd.old.sav backup, it contains a copy of all
           passwords at the time of conversion, although it is secured
           against world read-access.  It can come in very useful, however,
           if you just intend testing trusted system features, and intend
           'backing-out' later (see below).

    Notes: Passwordless users in original /etc/passwd file are converted
           into passwordless entries which are expired.  This is NOT any
           better secured that it was to start with, because such users are
           still able to login, they'll just be forced to enter new
           passwords when they do so.

    Notes: HP documentation claims that all users are forced to use
           passwords as part of the conversion process.  This may be true on
           some HP-UX versions only.  We've seen cases where passwordless
           user entries were misconverted by SAM, although this seems to
           have been resolved on HP-UX 9.0.

    A significant benefit associated with trusted systems is the
    availability of enhanced system auditing functions.  Many of these
    are only available with trusted systems, as they make use of the
    unique user Audit ID number assigned during the conversion process.

    There are a few problems associated with use of SAM, as summarized

    - SAM doesn't provide a menu item for turning off trusted system

    - if you want to experiment, and hope to revert to non-trusted
      status after your tests, don't.  There is no easy way to turn off.

      If you insist, the following list summarizes the necessary steps:

      1)  recover encrypted passwords from shadow password file, and re-
          insert them in the default password file.

      2)  Turn off auditing:
            /audsys -f

      3)  Remove the /.secure directory and its contents:
            rm -r /.secure

      Obviously, before performing these steps you should verify that the
      /.secure directory doesn't contain any other significant files.  Don't
      remove this directory until you've verified that steps 1 and 2 have
      been completed successfully.

      Be very careful when performing these steps, it's very easy to lock
      oneself out of the system if the correct encrypted passwords are not
      correctly merged back into the /etc/passwd file (this is where the
      backup file /etc/passwd.old.sav can come in useful).

  HP-UX Group Privileges

    HP-UX allows special attributes to be associated with groups.  It allows
    some superuser-like capabilities to be controlled by defining which
    groups they are accessible from.   In this way it becomes possible to
    distribute superuser accessible commands to other users without allowing
    them full access to all other superuser capabilities.

    This allows some (slight) relaxing of UNIX's 'all or nothing' approach
    to distributing privileged capabilities.  Privileged groups are an
    HP-UX specific feature.

    The following capabilities may be controlled:

    - setting real-time priorities
    - locking data in memory
    - changing file ownerships (chown)
    - lock file that are open for read access
    - use setuid() and setgid() to change process real user/group IDs

    In particular, this mechanism may be used to secure the chown command,
    which has the potential to be misused.  The chown command may be used to
    change the owner ID of a file (or files) to another specified owner.  By
    default, on HP-UX, this command may be used by any user to assign
    ownership of their own files to any other user, including root.

    For example, HP-UX's disk-space accounting facility may be used to
    report the total disk usage of all users.  It's possible for users to
    conceal their total disk usage by using the chown command to assign the
    ownership of their own files to other users.

    On BSD-derived UNIX implementations, chown usage is limited to super-
    users only.  By modifying the group privilege file /etc/privgroup via
    the setprivgrp command, it's also possible to close this loophole on
    HP-UX, by limiting usage of the chown command to users who are members
    of specified groups only.

    Although this doesn't appear to be covered by any HP documentation, it
    appears that users are assigned the group privileges associated with
    their primary group ID, and of all secondary groups defined within file

    HP-UX documentation recommends that you not rely on the privileged group
    mechanism to restrict access to the setuid and setgid system calls.
    They do not guarantee that it will be supported by future releases of

  Ambiguous Account UID and GID fields

    Although not specific to HP-UX, shared user ID numbers within the
    /etc/passwd file can cause problems in uniquely identifying users
    responsible for security breaches.

    By converting to trusted system status, the only area where the
    ambiguity is resolved is in the area of audit records.

    Ambiguous user/group ID numbers will create problems in the following

    - resolving file ownership
    - identifying the origin of system log records

    Despite what is claimed by HP-UX documentation, CRON log files do NOT
    seem to refer to Audit IDs, hence they are affected by ambiguous user/
    group ID entries.

File System Related Security Problems

  File System Security Implementation

    UNIX implements file access security at three levels (or domains):

    - owner access
    - group ownership
    - everyone else (world)

    At each level, access permissions are defined which control file access
    according to the type of operation, as follows:

    - read permission
    - write permission
    - execute (file) or search (directory) permission

    Each permission may be present or missing from each of the three levels,
    each permission and level are quite independent of each other.

    Permissions may be modified using the chmod command, and can be listed
    using ls -l (or ls -ld for directories).

    Program files may also have any of the following permissions associated
    with them:

    - set User ID capability
    - set Group ID capability
    - sticky-bit capability

    File access permissions are defined by the value of the Modes field,
    which is interpreted as follows (modes are displayed as an octal number,
    combining all 16 possible bit values into up to 6 numeric digits):

                                    ..................... read    | owner
                                    : ................... write   | access
      sticky bit .................  : : ................. execute |
                                 :  : : :
         set GID ............... :  : : :  .............. read    | group
         set UID ............. : :  : : :  : ............ write   | access
                             : : :  : : :  : : .......... execute |
          file | ..........  : : :  : : :  : : :
          type | ........ :  : : :  : : :  : : :  ....... read    | other
               | ...... : :  : : :  : : :  : : :  : ..... write   | access
               | ...  : : :  : : :  : : :  : : :  : : ... execute |
                   :  : : :  : : :  : : :  : : :  : : :
                   -  -----  -----  -----  -----  -----
                   O    O      O      O      O      O     octal digits

    When a file is built it is assigned the uid and gid of the creator.
    The default mask settings are determined by the current umask value.
    Umask may be set at the following levels:

    - system wide
    - user's environment file
    - at command line
    - programatically when file is created

    Although HP-UX conforms to standard UNIX implementation, it's worth
    noting the following:

    -  The three domains are not hierarchical, they are mutually exclusive.
       In other words, the file owner is NOT considered as a member of the
       file's group, and members of the file's group are not allowed file
       access via the world permissions.

    -  The file owner is generally the file's creator, but may be assigned
       to another user using the chown command.

    -  For directory files, write access allows the altering of privileges
       associated with files within the directory.  Read access allows the
       directory contents (list of files in the directory) to be listed, and
       execute (or search permission) access a program to use the directory
       as a component of a file's pathname.  The cd command requires search
       permission (only) to be used on a given directory.

    -  HP-UX uses the SETUID attribute on directories to indicate that the
       directory is hidden.  This is part of the HP-UX context dependant
       file structure.

  Sticky-Bits and Directories

    HP-UX provides an additional mechanism for protecting the contents of a
    directory, taken from System V UNIX:

    - if the directory 'sticky-bit' attribute is set, then files within the
      directory may only be removed (using the rm command) by the owner of
      the directory (or by users with write-access to the file).

    If this is not set, then any user possessing write and search (execute)
    access to the directory is able to remove a file regardless of whether
    they possess any access to the file itself.

    This is a useful feature, allowing a measure of protection to the
    contents of directories containing 'temporary' files intended for read-
    access by many users.

  HP-UX Shared Library Security Implications

    Shared library support, introduced with HP-UX 8.0, despite being
    thoroughly familiar to anyone who's worked on an HP3000, has created a
    few ripples in the HP-UX world.  And, no, we're not even talking about
    HP's inability to maintain forward compatibility between some shared
    libraries created under HP-UX 8.0, and run-time HP-UX 9.0 systems.  We
    speak from some experience here, after having tried to maintain software
    compatibility between HP-UX versions 7, 8 and 9.

    While a description of shared library implementation or use is beyond
    the scope of this paper, there are some security ramifications
    associated with their introduction.

    The directories /lib and /usr/lib contain many shared library files,
    used internally by HP-UX command files.

    If these directories are world-writable, then technically capable
    intruders could subvert the functioning of many system commands.

    Any tampering with the contents of these groups could easily be
    catastrophic for the system.

  HP-UX Access Control List (ACL) extension

    HP-UX implements an additional access control mechanism known as Access
    Control Lists (ACL), this is analogous to the Access Control Definition
    (ACD) mechanism implemented on MPE based HP3000s, and recently enhanced
    by the HP3000's entry into the world of POSIX-compliance.

    ACLs allow discretionary access control to be enforced, and allows
    access permissions to be defined at a finer level than that allowed by
    UNIX's traditional UNIX access modes.  File access may be allowed or
    refused on basis of user, group, or any combination.  File access may be
    allowed or restricted to individual users, regardless of what group or
    groups the user is a member of.

    On HP-UX the chacl command is used to change to access control list
    of a file, and the lsacl command is used to display ACL permissions
    associated with a file.

    Each entry specifies the r/w/x access permissions associated with a
    particular user ID/group ID combination.  Up to 13 elements may be
    specified in addition to the three 'base' elements always present.

    User and Group may be specified in any of the following ways:

    - name
    - number
    - '%' meaning any user or group
    - '@' meaning the current file owner or group

    When a file is created, the UNIX-style access permission word is mapped
    into an equivalent three-element ACL list:

      (uid.%,mode)  .. file owner base ACL entry
      (%.gid,mode)  .. file group base ACL entry
      (%.%, mode)   .. 'other' user base ACL entry

    The setacl command is used to add new ACL elements,

      (joe.tech, rwx)  -- allows r,w,x access to specified user
      (frank.%, ---)   -- refuse all access to user frank in no specific

    The following search order is used to determine if file access is

      - (user.group, rwx)   specified user and group
      - (user.%,     rwx)   specified user, any group
      - (%.group,    rwx)   any user, specified group
      - (%.%,        rwx)   any user, any group

    The entire list is always checked, and the entry that matches the
    request (the most specific matching entry) is used.  More specific
    entries anywhere in the ACL list take precedence over less specific ones
    that also match.

    If a process has a supplementary group IDs, the access mode of all
    matching entries that match at the same level are ORed together.

    By mapping the traditional UNIX access modes into the 'base' ACL
    entries, backward compatibility is provided.

    If more that one access is requested, then access is only provided if
    all requested accesses are allowed.

  Problems associated with ACL

    One of the more significant problems is the inability of the HP-UX PDF
    facility (see below) to correctly track file ACL descriptions.

    UNIX chmod command will lose ACL entries if an explicit effort is not
    made to preserve them (-A option).  This is because (to conform with
    POSIX .1 standard) optional entries are deleted.

    If UNIX chown command is used to change a file's user and/or group IDs,
    then any specific matching ACL entries will be remapped to the new
    values.  However, if the original file already contained an explicit ACL
    entry for the new user/group ID, then the ACL list is not changed, and a
    change in access permissions may result.

    ACLs should be used for user files & directories, not for files that are
    manipulated by system utilities.  These utilities may remove optional
    ACL entries without warning.

    Backup utilities should be checked: only fbackup and frecover can handle
    ACL correctly.  cpio and tar will lose optional ACL information.

    ACL specifications cannot be used in cases where user/group names
    contain .+%@ or * characters, so don't.

    ACL specifications cannot be transferred over a network.

  HP-UX 'Filesets'

    HP-UX uses a concept known as a 'fileset' when referring to logical
    groups of files that supply software functionality.  This term isn't
    used in the standard UNIX reference sources.

    A fileset description consists of two items: a directory located within
    the /system directory, and a file within the /etc/filesets directory.
    This file contains a list of all files considered part of the fileset.

    Individual files are never listed as being members of more than one
    fileset (at least, we've never seen this happen).

    HP-UX filesets are referred to in HP-UX Installation and Update
    procedures, where you may decide whether individual filesets should be
    installed or not, and also by the HP-UX rmfn (remove functionality)
    command, which allows unwanted features to be deleted from a system.

    In neither case are you able to remove a fileset that would be required
    for other (required) functionality to work.

    A fairly complete list of HP-UX filesets is found in Reference #8,
    Appendix A.

  HP-UX Product Description File (PDF) facility

    HP-UX contains a powerful facility that allows you to check whether
    files have been modified or not.  The facility may be used independently
    of the trusted system status.

    It offers a superset of the checking available on other UNIX
    implementations via the sum, cksum and upkeep commands.  Incidentally,
    although both checksum commands are available on HP-UX, there is no
    manual help available for the cksum command.

    HP-UX is delivered with a number of PDF input files, each containing
    information describing the file that are part of a particular fileset.

    Considering that the PDF facility gives you the ability to monitor
    changes in operating system files, it's quite surprising that the
    facility is so poorly documented in HP-UX documentation.  We've found
    references to it limited to man entries for pdf(4), mpdfck(1M),
    pdfdiff(1M) and mkpdf(1M) only.

    HP-UX fileset directories are located in the /system directory, the PDF
    input file for each fileset is stored as the file pdf, within each
    fileset directory.

    HP documentation recommends that you rebuild all PDF input filesets
    following (or as a part of) conversion to trusted system status.  We
    found this to be unnecessary, as a normal installation of new HP-UX
    version results in the installation of (theoretically) good PDF input
    specification files supplied by HP.

    PDF input files normally contain the name of the fileset at the start of
    the file, followed by one line for every file supplied with the fileset,
    with trailing lines specifying the total size of all files in the

    The following detail information is included on each file detail line in
    the PDF input file:

      pathname      .. absolute pathname ('?' indicates file is optional)
      owner         .. owner name or UID number
      group         .. group name or GID number
      mode          .. file type and permissions (ls -l format)
      size          .. size in bytes
      links         .. total hard links
      version       .. numeric revision number
      checksum      .. CRC checksum
      linked to     .. hard/symbolic linked files

    Any field may be blank, in which case the value is not checked.

    The following notes focus on particular PDF features:

    - checking PDF status
      The pdfck command is used to check the current status of files within
      a PDF fileset against the PDF input file specification.  Unfortunately
      the output of pdfck is very difficult to read.

    - CRC checksum.
      PDF uses the IEEE 802.3 Cyclic Redundancy Check (CRC) algorithm to
      derive a checksum value for each file, and is able to detect if this
      value has changed.  No information can be inferred, however, on the
      magnitude of changes that caused any checksum mismatch.

    - Standard compliance.
      The PDF is based on a draft proposal submitted to the IEEE POSIX .2
      committee.  The proposal was subsequently dropped from the standard.
      I'm not sure if any conclusions should be drawn from this.

    - File Access Mode changes.
      File access mode changes detect changes made to a file's access
      permissions, file type, Set UID and Set GID bits, and to the sticky-
      bit status of the file.

    - File Size Changes.
      The PDF input file stores the size of a file in bytes, or (for device
      special files) the major/minor device number.  Directory sizes changes
      are not detected.

    - HP-UX version 7 Limitations.
      The PDF facility was (apparently) not available on all HP-UX version 7
      systems.  In addition, the checksum algorithm used by HP-UX release 7
      is different from that used by releases 8 and 9 (which are, however,
      mutually compatible).

    The following limitations, some of which are major, apply to the PDF

    - Validity of input files.
      The validity of information as reported here is dependant on the PDF
      input file being correctly initialized.  If the input file does not
      correctly describe the files within a fileset, than this report will
      generate potentially large numbers of misleading error messages.

    - Detection of new files.
      PDF can't detect if new files have been added anywhere.  As a result
      it is of no help in detecting Trojan horses.

    - Covering dynamic files.
      PDF input descriptions generally do not cover system configuration
      files that the user is expected to setup, and files (such as system
      auditing log files) that change constantly.  Some other means should
      be used to verify that these files remain correctly secured.

    - Checksum algorithm weaknesses.  The CRC checksum algorithm may be
      spoofed fairly easily, that is, if a file has been modified, then the
      resulting checksum change may be 'canceled out' by changing another
      (unimportant) area of the file, and retrying different values until no
      checksum mismatch is detected.  To be considered reliable, a
      cryptographically sound checksum algorithm should be substituted.

    - Tracking ACL description changes.
      The PDF facility does not track or detect changes made to a file
      access permissions, if defined using Access Control List (ACL) syntax.
      Many ACL changes will in fact be detected, as many will change the
      equivalent access permission value, but this cannot be guaranteed.

      Bearing in mind that both PDF and ACL represent HP-written extensions
      to UNIX, it's somewhat unfortunate that PDF doesn't track ACL changes.

      As the following example shows, this is a significant loophole.

      Consider the security on the ps command file.  The following PDF
      description is contained within the UX-CORE fileset:


      checking this (via pdfck) reveals no problem.

      If the security on this file is modified to allow non-superuser access
      to the file:

        chacl "fred.users+rwx" /bin/ps

      as verified using the lsacl command:

        lsacl /bin/ps
        (fred.users,rwx)(bin.%,r-x)(%.sys,r-x)(%.%,r-x) /bin/ps

      then re-running the pdfchk on the UX-CORE fileset doesn't detect any
      problem at all with the file, despite that fact that a critical UNIX
      command file is now vulnerable to tampering by user fred.

    These problems aside, pdfchk remains a useful means of verifying that no
    significant files have been tampered with.

    On our system, following a correct installation of HP-UX 9.0 (and
    without going into details on the disc reorganizations required to
    effect that installation), out of the approximately 13274 input PDF file
    description entries, the following summarizes the total number of each
    type of PDF mismatch detected:

      deleted  : 388
      owner    :   1
      group    :  13
      links    :   5
      checksum :   7
      mode     :   3
      size     :   7
      version  :   0

System Logfiles

  List of Available Logfiles

    The following list is a (fairly complete) list of the system logfiles
    that are potentially available on an HP-UX system.  Compiling such a
    list was, as you might imagine, a non-trivial task...

    logfile                   type  contains...
    ------------------------  ----  ---------------------------------------

     /.secure/etc/auditlog_1        primary auditing logfile
     /.secure/etc/auditlog_2        secondary auditing logfile

     /etc/btmp                bin   bad login attempts.

     /etc/wtmp                bin   good logins, time changes, reboots.

     /etc/ptydaemonlog        asc   pseudo-terminal open/closing info (?)

     /tmp/clusterlog          asc   HP-UX cluster environment event logging

     /tmp/updatelog           asc   logs update and install commands, tracks
                                    update, install and removal of filesets.

     /usr/adm/pacct*          bin   accounting info (SVR4) (?)

     /usr/adm/sulog                 su command logging

     /usr/adm/OLDsulog              old su logfile, renamed on system reboot

     /usr/adm/syslog          asc   miscellaneous system log file.  User
                                    accessible logfile.

     /usr/srm/OLDsulog        asc   old syslog, renamed on system reboot

     /usr/adm/shutdownlog     asc   shutdown and rebooting log

     /usr/lib/cron/log        asc   logs use of cron, at commands

     /usr/lib/spell/spellhist asc   use of spell command (!)

     /usr/spool/mqueue/syslog asc   (?)

  Auditing on a Trusted System

    The HP-UX specific auditing subsystem solves one important limitation
    of traditional logging: the inability to resolve ambiguities between
    accounts having matching User/Group ID numbers.  As conversion to a
    trusted system assigns unique Audit ID numbers to every account, the
    auditing subsystem can always report the precise user responsible for
    any event.

    While the details are beyond the scope of this paper, SAM allows the
    configuring of the following categories of system activity:


      Individual users may be audited


      The following types of events may be logged:

        object creation, deletion, access permission modification
        object opening and closing
        process operations
        removable media mounting/unmounting
        user logins and logouts
        administrative and privileged operations
        interprocess communication
        user-defined events

      User-login logging is handled differently from other event classes:
      selected event classes are only logged for users who have themselves
      been selected for auditing, however when the user-login event class is
      selected, all user logins are logged regardless of whether the
      individual user is selected or not.

    System Calls:

        the individual system calls associated with the event list may be
        audited, as well as many significant programmatic calls, for example
        setuid and setgid.

    In general, you may log successful and/or unsuccessful attempts to
    access any of the above events.

Network Related Security Problems

  Network Security Overview

    The Network Information Service (NIS) is an optional network service
    that allows a single system (the NIS master server) to administer
    password, group and other files over the network.  Networked systems
    (the NIS clients) access the database files stored on the master server
    as if they were stored locally.

    The most significant aspect is that account and configuration data need
    only be maintained on a single machine in the network.

  Building NIS Databases

    ypmake is a shell script (located in /usr/etc/yp) that is used on the
    NIS server to build (or rebuild) the NIS databases.  Once ypmake has
    completed, yppush is used to notify NIS clients of the change, and to
    make them upload to updated maps to their machines.

    The standard NIS databases are created from the following ASCII files:


  NIS Authentication Weaknesses

    NIS possesses one weakness: the authentication mechanism used by HP's
    implementation is not completely secure.  Network clients that need
    password authentication to be performed by the master server present to
    the server a UID GID pair, and up to 8 secondary GIDs; the server uses
    these to determine if the request is authorized.  Unfortunately, the
    server has to trust that the client is providing the correct UID and GID
    data.  In essence, the client can claim to be any user, and the server
    has no way to verify this information.

    An important exception to this loophole presented by the superuser on
    the client machine.  Any authentication request that originates from a
    superuser (UID 0) is changed to UID -2, which is defined to be 'nobody'.
    As a result of this, the superuser on an NIS client has no special
    access rights on the NIS server.

    A user-written program running on an NIS client may set their UID/GID
    numbers to any required value, and may therefore access any file on the
    NIS server, as long as the file is not owned by root.

    In general, the NIS server may be protected against this kind of hostile
    attack by a number of mechanism, including limiting the filesystems that
    are exported, by exporting them read-only, by limiting the machines to
    which they are exported, or by setting the owner of sensitive files to

  Network Password Files

    An NIS client site's system password file /etc/passwd (or the secure
    /.secure/etc/passwd) can contain entries that begin with a '+' or '-' in
    the first column.

    Such entries cause the NIS master server to be queried, and any matching
    entries that it returns will be included or excluded on the NIS client
    site, as if they had been maintained locally.

    Such entries cause the inclusion (or exclusion) of entries located in
    the NIS server's Network Information System (NIS) network database file.

    Although a full description of the NIS database is beyond the scope of
    this paper, the following points should be noted by users who have
    converted to trusted system status, and who therefore are using a
    secured shadow password file:

    In this case, encrypted passwords previously held in the /etc/passwd
    file are now stored in /.secure/etc/passwd.  In this case, the NIS
    database will not contain encrypted passwords, as it extracts encrypted
    passwords from the standard /etc/passwd file.  As the NIS database is
    itself readable by anyone with access to NIS commands such as ypcat,
    this is necessary to prevent security from being compromised.

    According to HP documentation (reference #9), the following steps must
    be performed if you wish to use the NIS database to maintain other data
    held in the password file, while still keeping encrypted password data

    1)  Build the NIS password database on the master server using a
        /etc/passwd file that doesn't contain encrypted passwords.

    2)  On NIS client sites using HP-UX, keep a copy of /.secure/etc/passwd
        containing (correctly secured) encrypted passwords.

    3)  On non-HP-UX NIS clients, use the NIS escape syntax to keep
        encrypted passwords in the NIS client system's /etc/passwd file.

        In this case, the NIS server will authenticate the supplied
        username, but the encrypted password held locally will be used
        for password checking.

  Remote System Administration

    HP-UX release 9.0 contains some significant enhancements related to the
    remote management of network security.  In particular, SAM now contains
    a Remote System Administration area that allows system management to
    remotely administer networked systems.

    Although this feature has only recently been released, preliminary
    investigation has revealed the following:

      When remote system administration is requested, SAM logs in to the
      remote system, and creates a new account on the remote system (you
      must provide the root password to the remote system to do this).

      The new account is created with user name sam_exec, UID=0 and GID=1,
      and is created with a copy of the root password currently used on the
      remote system.  This new account is used by SAM whenever logging in to
      the remote system.

    While not in itself a problem, this seems to be very lightly (if at
    all) documented at present.

  HP-UX DSCOPY logging limitations

    DSCOPY displays no evident security problems, with the exception of the
    following:  no logging of either successful or unsuccessful DSCOPY login
    attempts from remote systems is performed.  At present, this seems to be
    an unnecessary loophole, allowing brute-force security attacks to be
    performed without leaving any trace of the number, time or origin of the

    The B1 certified HP-UX BLS version does contain facilities for logging
    these attempts, but no such facility exists in standard HP-UX.

Security Auditing Techniques

  VESOFT's SecurityAudit/UX

    VESOFT have recently released a security auditing tool for HP-UX based
    systems.  While this is not the forum to promote the product, we make
    use of a number of techniques that may be of interest.

  Managing PDF output

    VESOFT's SecurityAudit/UX product makes use of the supplied PDF files to
    verify file system consistency, but performs a number of additional
    checks to close the loopholes noted here.  In particular, we track
    changes to file ACL descriptions, and flag new files not covered by any
    PDF description file.  We also can report on files that we consider to
    have weak security, regardless of whether they are covered by a PDF
    description file.  Another very useful feature is the ability to
    summarize the somewhat verbose output of the pdfck command, by
    generating output reports that contain the number of each type of
    violation detected within each PDF fileset.

    It's also very important to realize that any sufficiently capable
    intruder is able to modify or even add a new PDF description of a file
    that has been altered or added.  It's vital to track changes to the PDF
    input files themselves, and to maintain backup copies in secure
    locations.  We intend to maintain encrypted versions of these files to
    prevent even superuser intruders from tampering with the file

  Tracking File System Changes

    VESOFT's SecurityAudit/UX product tracks changes to file system status,
    specifically to allow changes in file ACL specifications to be detected,
    and to track when files are created and deleted.

    We encountered problems when trying to determine the date on which a
    file was created, due to a number of 'features' of HP-UX.  In particular
    every file has the following date/time fields associated with it:

    - atime   access status : last access time of file data
    - mtime   mod status    : last modification of file data
    - ctime   change status : last change time of i-node status

    These time fields are changed by the following actions (among others):

    - atime   read operations
    - mtime   write operations
    - ctime   file access permissions, userid, links change operations

    However, there is no i-node last access time, hence access and stat
    functions don't modify any of the three time fields.

    The time fields are maintained for directories just as for any other
    file type, with the difference that directory data is modified when a
    file within it is added or deleted.

    The shell ls command can be used to display these fields.  Possible uses
    for the fields are to delete files that haven't been accessed since a
    certain date, or to archive files that have been modified since a
    certain time.

    The touch command may be used to update any of these time fields to
    either the current time, or to any specified time, depending on the
    user's capabilities.  In particular, a file creator may set a file's
    access and modification times to any value.  The i-node change time
    can't be set to an arbitrary value, but it will be updated to the
    current time.

    On HP-UX, the fbackup utility may be used to perform an incremental
    backup, in which files are only backed up if they have been modified
    since a previous backup of the specified fileset.  The fbackup utility
    performs this by maintaining a database (/usr/adm/fbackupfiles/dates by
    default) which records this information.  However, fbackup will modify
    all file inode change times to the current time the file is backed up.

    This has an unfortunate effect on security auditing: it is impossible to
    tell how old a file is by looking at any of the change time fields.
    There is no equivalent of the HP3000 file creation time field, which
    greatly complicates the life of a security auditing tool which attempts
    to identify all newly created files on a system.

    From a security auditing viewpoint we are most concerned about use of
    the command to modify a file's modify or change date backwards, with the
    intention of concealing a modification of the file's contents or access
    permissions or ownership.

    VESOFT's SecurityAudit/UX product is able to determine if a file is
    newly created or not by maintaining an internal history database.  We
    record the first time that we see a file, and the file's i-node number.
    On subsequent runs of the program we check the file's change dates and
    i-node, and we can infer from this information if a file has been
    modified since the last run.  Currently we make use of this information
    to derive two information fields: firstly the (approximate) age of a
    file, and secondly a flag that indicates if any security problem
    associated with the file has been newly detected, or has existed for the
    entire life of the file.

    This information is significant because it enables us to identify newly
    created security problems: obviously a number of improperly secured
    files may exist on your system, and we aren't always able to determine
    whether or not the security problem can be solved without breaking a
    program that requires the file's security to be the way it is.  On the
    other hand, a change in file security of a file that used to be
    'correctly' secured is an indication of a significant security problem,
    and we'll flag it as such.

  Resolving Ambiguous User/Group IDs

    One facet of analyzing system accounting records that is somewhat poorly
    handled by HP-UX commands is the area of resolving ambiguous user IDs
    stored in accounting log records.  We try to not only flag shared user
    IDs as a potential problem, but in many cases we are able to resolve the
    ambiguity by checking through the list of users who share a given user
    ID, while ignoring users who are not also members of the logged group

    We use the same technique when trying to determine the unambiguous owner
    of a file.  The ls command (for example) shows file user and group names
    by scanning through /etc/passwd and /etc/group looking for the first
    matching entry in each file, respectively.  We can be slightly more
    intelligent by looking for the first matching user who potentially has
    access to the file's group.  It's not guaranteed to resolve the
    ambiguity, but it increases the chances.


  I'd like to express my thanks to the following:

  - Serge Bojoulitch, principle developer of VESOFT's SecurityAudit/UX
    product, for his work investigating HP-UX security issues, and for the
    many suggestions and ideas he contributed to this paper.

  - Eugene, Vladimir and Anne Volokh, for their help and encouragement
    during the development of SecurityAudit/UX.

  - Our numerous beta test sites, for their feedback and criticism during
    product development, and even for the occasional bug report...


  The following sources provide information on general UNIX security topics:

   1)  UNIX System Security.  Rik Farrow.
       Addison-Wesley, 1991.  ISBN 0-201-57030-0.

   2)  UNIX System Security.  David A. Curry.
       Addison-Wesley, 1992.  ISBN 0-201-56327-4.

   3)  Practical UNIX Security.  Simson Garfinkel and Gene Spafford.
       O'Reilly & Associates, 1991.  ISBN 0-937175-72-2.

   4)  UNIX Security.  N. Derek Arnold.
       McGraw-Hill, 1993.  ISBN 0-07-002560-6.

   5)  The Cuckoo's Egg.  Clifford Stoll.
       Doubleday, 1989.  ISBN 0-385-24946-2.

  The following sources provide information on HP-UX specific security

   6)  VESOFT SecurityAudit/UX User Manual (version 1.6).
       VESOFT, Inc, 1993.

   7)  HP-UX System Security Manual (2nd edition).
       Hewlett Packard, 1992.  Manual Part Number B2355-90045.

   8)  Installing and Updating HP-UX 9.0.
       Hewlett Packard, 1992.  Manual Part Number B2355-90039.

   9)  Installing and Administrating NFS Services (2nd edition).
       Hewlett Packard, 1992.  Manual Part Number B1013-90009.

  10)  How HP-UX Works: Concepts for the System Administrator (4th edition).
       Hewlett Packard, 1992.  Manual Part Number B2355-90029.

The Author

Paul Taffel has worked with HP3000 systems for the past 10 years, and has
held product management and development positions at Bradmark Computer
Systems in Houston (working with DB-General), and at APPIC in Paris
(developing StarJet/3000).

Paul currently works as a software developer with VESOFT in Los Angeles,
where he divides his time between enhancing VESOFT's HP3000-based products,
and managing development of VESOFT's HP9000-based SecurityAudit/UX product.

Go to Adager's index of technical papers