Security responsibilities and considerations

z/OS UNIX maintains system security by verifying user identities and file access control information. A PFS is primarily concerned with file access control.

For those functions where POSIX .1 (IEEE Standard 1003.1-1990) specifies that "appropriate privilege" is required, the PFS refers to a bit that is set by the LFS to determine whether the function has appropriate privileges. For more information, see "Appropriate Privileges" in the POSIX standards.

Access control checks are based on information that is stored with each individual file, and are generally carried out on the system where the data resides.

Access control is integrated with the SAF interface to call RACF®, or whichever security product is used at a particular installation.

The basic flow of file security is as follows:

Security information, such as the owner's UID-GID and the permission bits for a file, is kept in a 64-byte area called the file security packet (FSP), which is mapped by IRRPIFSP. The FSP is the security-related section of a file's attributes.
The FSP is created by a SAF call from the PFS when a file is created. Some of the information is taken from the current security environment, and some of it is passed as parameters.
The PFS stores the FSP with the attributes of the file.
When an access check is to be done, the PFS calls SAF with the type of check that is being requested, the audit_structure from the current call, and the file's FSP. SAF passes these to the security product, which extracts user information from the current security environment and compares it against the access control that is stored within the FSP. The audit_structure is used primarily for any auditing that may be necessary.
There are many access and privilege checks defined by the POSIX standards. The detailed description of each vnode operation in PFS operations descriptions discusses the access checks that are expected.
When a file's access control information is changed, such as by chmod(), the PFS calls SAF with the type of change, the new values, the audit_structure from the current call, and the file's current FSP. A new version of the FSP is returned to the PFS, which then replaces the file's old FSP with the new one.
When a file is deleted, the PFS discards the FSP.

In the flow described previously, the PFS provides some private space within the file attributes for the security product's use, ensures common access checking across all PFSs, allows for the installation of different security products, and lets the security product perform auditing or other non-POSIX processing.

The PFS is ultimately responsible for the following access checks:

If the PFS controls the storage of its own files, it follows the flow outlined in this topic to create, maintain, and use security information.
If the PFS is a client getting its data from some remote repository, it sends the request to the remote system, where the access checks are performed using the osi_getcred service.
If access is not controlled for the type of data that is supported by a particular PFS, the PFS may choose to skip these security procedures.

Some events that occur in the LFS are audited for security purposes by the vn_audit operation. For example, because relative pathnames may be audited during an access check, it is important to audit the working directory so that a full pathname can be constructed if necessary. When a user calls chdir() or fchdir(), the LFS invokes vn_audit to record the new working directory. chroot(), which changes the current root, is another call that causes an audit record to be created.

Refer to z/OS Security Server RACF Callable Services for more information about these interfaces.

PFS support for multilevel security discusses PFS responsibilities and considerations for multilevel security.