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 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
As of MPE/iX Release 4.5, ACDs were
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. As of
MPE/iX Release 4.5, the access of the owner can be restricted by using
the new subject $OWNER. Let us see how an ACD is evaluated on an MPE/iX
Release 5.0 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.
As of 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 you
specified a lockword, it resulted in an error; a lockword violation.
However, as of MPE/iX Release 4.5, it is not an error. Indeed, no
security violation has occurred.
To put an ACD on a file protected by a lockword, you must pass the
lockword check. This is a new rule as of MPE/iX Release 4.5.
Lockwords cannot be provided in a filename 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
As of Release 4.5, MPE/iX 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 to all users.
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:
* Manager's Guide to MPE/iX Security (32650-90474)
* User's Guide to MPE/iX Security (32650-90472)
* New Features of MPE/iX: Using the Hierarchical File System
(32650-90351)