Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1641 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1641.

Report 1641 Actions

    Problem Report Number 1641
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0198
    Raised 2000-12-08 08:00
    Updated 2003-03-13 08:00
    Published 2001-03-14 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.1.1
    Test Identification CAPI.os/procprim/vfork 8
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN4U.00064 The test may fail on systems which have implemented extra security controls for catopen().
    Problem Text
    The actual assertion being tested by vfork 8 is:

    ** void test8A() - tests the assertion:
    ** A child process created by a successful call to pid_t vfork(void)
    ** shall inherit the parent process' message catalog descriptors.

    This refers to the section in the SUS (v2) dealing with fork():

    The child process may have its own copy of the parent's message
    catalogue descriptors.

    The reasons for the failure are two-fold: the fvfork1
    executable created by VSU is setuid/setgid to root/root and the
    message file being loaded by catopen inside the test possesses
    ownership and modification bits that are considered "insecure".

    VSU attempts to use a file called ApTest.cat instead of one of the
    system message files. The permissions on this file are 666 and the
    owner is the vsu0 user. Allowing such a file to be used by catopen
    when called by a setuid/setgid application is a potential security hole.

    The second problem involves the permissions on the executable program that
    tries to open the message file. The test is setuid/setgid to the root
    user and group. When executed, the effective uid and gid do not match the
    actual uid and gid of the user executing program, which in this case is
    vsu0. For this to be tested, or used, the executable does not have to be
    setuid or setgid.

    In the specification for catopen in System Interfaces and Headers,
    Issue 5, Volume 1, in the section "Application Usage" it says in the
    3rd paragraph:

    "Application writers should be aware that guidelines for the location
    of message catalogues have not yet been developed. Therefore they
    should take care to avoid conflicting with catalogues used by other
    applications and the standards utilities."

    Since guidelines have not been set forth for where catalogues should
    be placed, adding a security policy regarding the location of
    message catalogues does not conflict with the standard.

    The reason for the return value of ENOENT is that, for setuid/setgid
    application, only secure locations are allowed for a message catalog
    file. In this case, since the executable is setuid/setgid, the
    message catalogue does not exist in one of these secure locations, so
    catopen is unable to find the file. When the file is not found,
    the file open procedure returns a null to catopen, which in turn
    returns a -1 to the test

    If the executable is made to be either not setuid/setgid or is
    setuid/setgid to vsx0/vsxg0 then the test passes.
    Test Output
    ************************************************************************
    /tset/CAPI.os/procprim/vfork/T.vfork 8 Unresolved

    Test Information:
    ERROR: catopen failed, errno = 2(ENOENT - No such file or directory)

    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Security concerns related to catopen() were raised earlier this year.
    Presumably this test failure occurs as a result of changes made to
    the system to address these concerns.

    However, the security issue in question relates to the use of
    NLSPATH to locate the message catalogue. In the test, an explicit
    catalogue location is given in the catopen() call. So although
    changes have been proposed to the specification to allow for security
    restrictions in catopen(), they will probably relate only to the use
    of NLSPATH, and would not affect this test.

    Since the changes to be made to the specification have not yet been
    finalised, this interpretation request should be forwarded to the
    Base Working Group for review.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for a 14 day anonymous review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The working group recommends that a permanent interpretation be granted,
    see Base WG mail sequence 3957 for background information.
    A resolution bwg2001-01 has been finalized and a corrigenda will
    be generated shortly.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority