[Public Interpretations Database]

I-0001: Delayed Enforcement Of Authorization Change


NUMBER:               I-0001
STATUS:               Approved by CCEVS Management and Mailed to Public Mailing
                      List

TITLE:                Delayed Enforcement Of Authorization Change
APPROVAL POSTING:     [announce 0355]

EFFECTIVE:            1994-04-19

REQUIREMENT:          Identification and Authentication
CRITERIA CLASSES:     C1, C2, B1, B2, B3, A1
DOCUMENT(S):          Trusted Facility Manual
RELATED TO:
     I-0002           Delayed Revocation Of DAC Access
     I-0003           Access Validation After Object Label Change
     I-0004           Enforcement Of Audit Settings Consistent With Protection Goals
     I-0239           Subject Access Revocation After Change In User Clearance

STATEMENT:

The following interprets the requirements that at C1 ``The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user.'' and at B1 ``Furthermore, the TCB shall maintain ... information for determining the clearance and authorizations of individual users. This data shall be used ... to ensure that the security level and authorizations of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.''

If a TCB supports security-relevant authorizations then it shall provide a method for immediate enforcement of removing those authorizations. However, the immediate method (e.g., shutting the system down) need not be the usual method for enforcement. The TFM shall describe both the usual enforcement of granting and removing authorizations and, if the immediate enforcement method is different from the usual one, how an administrator can cause immediate enforcement.

PROJECTED IMPACT:

Negligible impact anticipated.

SUPPORT:

The term ``security-relevant authorization'' is used here to mean a capability, assigned administratively to some user or users, to perform security-relevant operations not permitted ordinary, untrusted users (e.g., in Secureware type Unix systems, privileges). The term ``authorization'' is not intended to cover controls on routine access to data by untrusted users; that is handled through the DAC and MAC mechanisms. Examples of authorizations include:

  • Ability to act as system administrator

  • Ability to set audit control parameters

  • Ability to act as system operator

  • Ability to manipulate others' requests in printer queues

  • Ability to use unlabeled import/export media

  • Ability to change other user's passwords

  • Ability to downgrade objects

Many authorizations could have serious consequences if misused, so an immediate revocation method must exist. In most situations (e.g., a change in job responsibilities), immediate enforcement is not required.