HP 3000 Manuals HP 3000 Manuals
MPE/iX File Access and Security Enhancements
by Rajesh Lalwani
Commercial Systems Division
The standard file access control mechanism of POSIX uses file permission
bits. It is quite different from the security model used by MPE, which
is based on several mechanisms: file access matrix, capability,
lockwords, and access control definition (ACD) to name a few.
POSIX.1 MODEL
Let us first look at the model used by POSIX. A process can access a file
in the following ways: read (R), write (W), and execute/search (X).
Search access applies to a directory whereas execute access applies to an
executable file like a program or a shell script file. There is a subtle
difference between read (as applied to a directory) and search access.
If a process wants to open a directory and read the entries in it, the
process needs read permission for that directory. But if a process wants
to access a file, say, /users/jeff/addr_bk, the process needs search
permission for all the directories in the path, namely, /, users, and
jeff in this particular case.
Every file in the directory structure has file permission bits associated
with it. File permission bits contain the file access control
information about a file that is used, along with file and process
attributes, to determine whether a process has read, write, or
execute/search permission to that file. The bits are divided into three
classes: owner, group, and other. In addition to the file permission
bits, there is a user ID (owner UID) and a group ID (file group GID)
associated with every file.
For the purposes of access control, processes are classified as belonging
to one of three access classes: file owner class, file group class and
file other class.
A process is in the FILE OWNER class of a file if the effective UID of
the process matches the user ID of the file. A process is in the FILE
GROUP class of a file if the process is not in the file owner class and
if the effective GID or one of the supplementary GIDs of the process
matches the group ID associated with the file. A specific implementation
of POSIX may define additional members of the file group class. Lastly,
a process is in the FILE OTHER class of a file if the process is not in
the file owner class or file group class.
The standard file access control mechanism of POSIX uses the file
permission bits described above. The bits are set at file creation time
and can be changed by the chmod() function. These bits can be read by
calling the stat() or fstat() functions.
rwx rwx rwx
--- --- ---
/ | \
/ | \
/ | \
|
File Owner Class | File Other Class
|
File Group Class
Implementations of POSIX may also provide additional or alternate file
access control mechanisms or both. An additional access control
mechanism can only further restrict the access permissions defined by the
file permission bits. An alternate access control mechanism, if enabled,
is used instead of the standard mechanism. The alternate access control
mechanism has some constraints, the chief being that it must be enabled
only by explicit user action, on a per-file basis. Also, the alternate
access control mechanism must be disabled for a file after the file
permission bits are changed for that file with chmod() function.
Lastly, POSIX also allows privilege based security in which access may be
granted to a process if it has appropriate privilege. Each POSIX
implementation can define what constitutes an appropriate privilege.
INTEGRATING THE TWO WORLDS
Implementing POSIX.1 on MPE requires a mechanism which conforms to the
POSIX.1 standard. Existing MPE access control mechanisms do not satisfy
the requirements specified in this standard. File user types defined for
the file access matrix are not exclusive categories. XL Release 3.0 ACDs
cannot express access permissions for a file's owner or group.
POSIX.1 file permission bits have not been implemented as a separate
access control mechanism. The POSIX.1 functions support the file
permission bits as a view of the ACD mechanism. ACDs themselves have
been enhanced to enable the ACD mechanism to operate as a POSIX.1
additional access control mechanism and to provide directory access
control. MPE applications will need to be aware of these enhancements.
The following figure illustrates the relationship between MPE ACD
intrinsics, POSIX.1 interfaces using file permission bits, and the ACD
mechanism.
ACD Intrinsics POSIX.1 API
(ACDs) (File Permission Bits)
\ /
\ /
\
\ Translation
\
\ /
\ /
ACD Mechanism
POSIX.1 applications will continue to use POSIX file permission bits to
specify access permissions and will be unaware that file permission bits
are implemented as an interface to the ACD mechanism. On the other hand,
MPE applications will never see POSIX file permission bits; they will see
ACDs, the file access matrix, and lockwords. When a POSIX.1 interface
such as open() creates a file, an ACD will be assigned to the file as
part of the file creation operation. When the POSIX.1 function chmod()
is invoked to set access permissions for a file or directory, ACD
information will be manipulated. Similarly, stat() and fstat() functions
evaluate an ACD and map the access permissions granted by the ACD into
file permission bits.
The following figure illustrates the relationship between R,W,X bits as
used by POSIX.1 interfaces and R, W, X, RD, CD, DD and TD as used by the
MPE/iX ACDs. RD,CD,DD, and TD apply to directories and stand for Read
Directory Entries, Create Directory Entries, Delete Directory Entries,
and Traverse Directory respectively.
POSIX.1 Permission Bits
rwx
/ | \
/ | \
/ | \
/ | \
Files R W X
Directories RD CD/DD TD
MPE/iX Permissions
On MPE/iX Release 4.5, ACDs have been enhanced to include three new
subjects: $OWNER, $GROUP and $GROUP_MASK. ACDs created by POSIX.1 file
interfaces will contain four ACD pairs: $OWNER, $GROUP, $GROUP_MASK and
@.@. The following figure illustrates the mapping between file
permission bits and ACD entries. All four ACD pairs are also granted
RACD (Read ACD) access.
POSIX.1 Permission Bits
File Owner File Group File Other
rwx rwx rwx
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
(RACD,R,W,X:$OWNER; RACD,R,W,X:$GROUP,$GROUP_MASK;RACD,R,W,X:@.@)
----- ----- -----
MPE ACD
On MPE/iX, the three new subjects are defined as follows: $OWNER matches
a process whose Effective UID is the same as the file's UID. $GROUP
matches a process whose Effective GID is the same as the file's GID.
$GROUP_MASK restricts the file group class entries of an ACD. All ACD
entries except for $OWNER and @.@, notably the user.account and @.account
entries, are part of the file group class. The ACD subjects $OWNER,
$GROUP, and $GROUP_MASK cannot be used with device ACDs.
ACD EVALUATION
On a Pre-4.5 release system, ACD evaluation proceeds from a more specific
to a less specific subject. If a particular file had the following ACD
associated with it:
R : MGR.PAYROLL
R,W : @.PAYROLL
R,W,X : @.@
the user MGR.PAYROLL matches all three subject descriptions. But since
ACD evaluation proceeds from the more specific to the less specific
descriptions, MGR.PAYROLL will only have R access according to this ACD.
The case where MGR.PAYROLL is actually the creator (owner) of this file
is very interesting. On Releases 3.0 and 4.0, the owner's access cannot
be restricted by an ACD or the file access matrix. So on 3.0 and 4.0
systems, MGR.PAYROLL still has all the access permissions on this file
even though the pair R:MGR.PAYROLL grants only R permission. On an
MPE/iX Release 4.5 system, the access of the owner can be restricted by
using the new subject $OWNER. Let us see how an ACD is evaluated on
MPE/iX Release 4.5 system.
Let us assume that a file /PAYROLL/PUB/dir/my_file has the following ACD:
R : $OWNER
R,W : MGR.PAYROLL
R,X : @.ACCTNG
R,X : @.PAYROLL
R,W : $GROUP
R,W : $GROUP_MASK
R,W,X : @.@
Let us also assume that the file's UID is MGR.PAYROLL, actually a number
associated with the string MGR.PAYROLL, and the file's GID is PAYROLL,
again, actually a number associated with the string PAYROLL.
On MPE/iX Release 4.5, an ACD is evaluated in the following order:
1. Are you the owner of the file?
You are the owner of the file if your effective UID matches the UID of
the file.
If the ACD has a $OWNER entry, you only have the access permissions
specified by the $OWNER pair of the ACD. If the $OWNER entry does not
exist, you have all access permissions for the file.
In our example, a user MGR.PAYROLL matches the $OWNER entry of the ACD
and hence has only the R permission even though MGR.PAYROLL is the
creator (owner) of the file. Notice that MGR.PAYROLL did not match the
entry MGR.PAYROLL in the ACD because $OWNER comes before anything else in
the evaluation order.
If the ACD did not have the $OWNER entry, MGR.PAYROLL would be granted
all access to the file even though the ACD has a MGR.PAYROLL entry.
2. Do you match a USER.ACCOUNT, $GROUP, or @.ACCOUNT ACD entry?
If you do, you belong to the file group class and your access permissions
are the permissions granted by the matching ACD pair, subject to the
maximum of the permissions granted to $GROUP_MASK.
If you match both a $GROUP and an @.ACCOUNT entry, you are granted the
access permissions granted by EITHER ACD entry. Of course, the
permissions are still subject to a maximum of the permissions granted by
$GROUP_MASK.
For our example file, a user ENTRY.PAYROLL matches both @.PAYROLL and the
$GROUP entries and hence has R,X from @.PAYROLL and R,W from $GROUP
entries for a total of R,W,X permissions. But since it is subject to a
maximum of $GROUP_MASK permissions which are R,W in our case, the user
ENTRY.PAYROLL has R,W permissions according to this ACD.
A user MGR.ACCTNG matches the @.ACCTNG entry in the ACD and hence has R,X
permissions. But since it is subject to a maximum of the permissions
granted by $GROUP_MASK (that is, R,W), the user MGR.ACCTNG will only have
R access permission according to this ACD.
3. Is there an @.@ ACD entry?
In this case you belong to the file other class and you are granted the
corresponding permissions.
For example, a user MGR.PAYABLE will belong to the file other class and
have R,W,X permissions for the example file.
If there is no @.@ entry in the ACD, you are granted no access to the
file.
Dynamic Nature of $OWNER and $GROUP
The $OWNER and $GROUP ACD entries provide a dynamic versus a static
characteristic to the ACD. For example, if the system manager changed the
example file's owner from MGR.PAYROLL to MGR.PAYABLE, then MGR.PAYABLE
(and not MGR.PAYROLL) will match the $OWNER entry of the ACD and have R
permission to the file. Before the owner changed, MGR.PAYABLE had R,W,X
permission to the file as MGR.PAYABLE belonged to the file other class.
Lockwords
Prior to MPE/iX Release 4.5, if a file did not have a lockword, and the
user specified a lockword, it resulted in an error; a lockword violation.
However, on a MPE/iX Release 4.5 system it is not an error. Indeed, no
security violation has occurred.
To put an ACD on a file protected by a lockword, the user must pass the
lockword check. This is a new rule for MPE/iX Release 4.5.
Lockwords cannot be provided in a file name using HFS syntax. Also, when
a file is accessed using HFS syntax, the system does not prompt for a
lockword. Thus, one cannot use the chmod() function on a file protected
by a lockword.
Appropriate Privilege
POSIX.1 refers to processes with appropriate privilege. Processes with
appropriate privilege bypass discretionary access control mechanisms:
file access matrix and ACDs. However, even a process with appropriate
privilege cannot bypass the following security mechanisms: file's write
protection bit in the file label, negative file code, file privilege
level, and lockword.
Let us see what constitutes an appropriate privilege on MPE/iX. A process
with SM capability has appropriate privilege to all objects (files and
directories).
Also, a process with AM capability has appropriate privilege to all
objects whose file group GID matches the process' effective GID (logon
account). Note that a user with AM capability is not AM for all the
files in his or her account because the GID of some of the files could be
different from the account in which these files exist. This could have
been done either by the chown() function or RENAME. This behavior is
different from the way AM capability worked before MPE/iX Release 4.5.
Required ACDs
An ACD is required on the following objects: HFS Directories, files not
directly below MPE groups (such as /PAYROLL/PUB/dir/my_file), and objects
directly below MPE groups whose GIDs do not match the GIDs of the
accounts in which they exist.
For objects for which an ACD is required, an ACD is always created when
the file is created and the ACD cannot be deleted. If you want to
replace the ACD on such an object, the DELACD and NEWACD parms of the
ALTSEC command cannot be used because DELACD will not be permitted on
such an object. A new keyword called REPACD (for replace ACD) can be
used to accomplish the task.
You cannot remove the ACD from such objects using the ;NOACD option of
the STORE subsystem. Even though ;NOACD is specified, the ACD will be
stored and a warning will be displayed.
STORE
MPE/iX Release 4.5 provides ;TRANSPORT=MPEXL option for the STORE
subsystem. MPEXL refers to a pre-4.5 release system. Since $OWNER,
$GROUP and $GROUP_MASK entries are not supported on pre-4.5 release
systems, STORE with ;TRANSPORT=MPEXL should be used when transporting
files with ACDs to pre-4.5 release systems. The ACD is translated
according to the following rules. Note that once such a translation
takes place, the dynamic nature of $OWNER and $GROUP as discussed earlier
is lost.
* $OWNER
If the ACD has a $OWNER entry, build or replace a USER.ACCOUNT
entry where USER.ACCOUNT is the current owner of the file.
* $GROUP
If the file's GID is the same as the account ACCOUNT and there is
no @.ACCOUNT entry in the ACD, build an @.ACCOUNT entry. On the
other hand, if an @.ACCOUNT entry exists, modify the permissions
granted by the @.ACCOUNT in the new ACD to be the combination of
the permissions granted by either the $GROUP or the @.ACCOUNT
entries in the old ACD.
* $GROUP_MASK
If there is a $GROUP_MASK entry, look at all the ACD entries that
belong to the file group class in the old ACD. Modify the
permissions granted by them so they grant no more access than the
permissions granted by the $GROUP_MASK entry.
RESTORE
RESTORE will work in the following manner:
* Anyone can RESTORE a released file.
* To RESTORE a file with the ;NOACD option requires the same
privilege as the DELACD operation of the ALTSEC command on the
same file: the file creator or a user with appropriate privilege
for the file.
EXECUTE (X) Access
Because POSIX doesn't provide a means of distinguishing regular files
containing executable scripts from regular files containing other types
of data, POSIX.1 states that file permission bits should be checked to
verify that execute access has been granted to at least one of the file
classes. Execute access being granted to one of the file classes is used
as an indication that the file contains executable statements.
When ALL access would normally be granted to a process, X access is
handled as a special case.
Users with appropriate privilege are granted X access only if the file
has an executable file code (PROG, SL, NMPRG, NMXL), or the file access
matrix or ACD grants X to at least one user.
The file creator is granted X access only if the $OWNER ACD entry grants
X access. If the $OWNER ACD entry does not exist, then X access is
granted if the file has an executable file code or at least one user has
been granted X access by the file access matrix or ACD.
A released file grants X access only if it has an executable file code.
These rules do not affect the other uses of X access on the system.
Users with appropriate privilege will still get X access to files with
executable file codes. X is also used to grant STREAM access to JOB
files. Users with appropriate privilege can still STREAM these files
because they have R access to the files.
CWD AND FILE SECURITY
It is now possible to change the current working directory (CWD) to any
directory (including an MPE account, an MPE group, the root directory, or
an HFS directory) as long as you have TD access for the directories in
the path to the directory. This means that you can change your CWD to
any MPE group on the system as everyone has RD and TD access to the root
directory and all the accounts and groups. It should be noted that
changing your CWD to another group doesn't make you a GU user. GU is
based on your logon group (or home group) and account which can only be
changed by CHGROUP. CWD is only a shortcut for file naming. No password
check is done when you change only your CWD, unlike CHGROUP which does a
password check.
ADDITIONAL INFORMATION
For further information consult the following documents:
* MPE/iX Reference Supplement (32650-90353)
* Controlling System Activity (32650-90155)
* New Features of MPE/iX: Using the Hierarchical File System
(32650-90351)