15    Introduction for Programmers

This chapter describes the implication of running trusted applications on a trusted Digital UNIX system. Libraries, header files, the standard trusted system directories and the trusted computing base (TCB) are discussed. This chapter and the ones that follow use partial and complete C programs to illustrate basic ideas. Although some of these can be used without modification, they are not a collection of routines from which you can assemble trusted programs.

15.1    Libraries and Header Files

Your system documentation contains reference pages for all new security system calls (section 2) and routines (section 3).

The libsecurity.a, libsecurity.so, libaud.a, and the libaud.so libraries hold all new enhanced security interface binaries. Use the -l compilation option to link these into your program, for example:

$  cc ... -lsecurity -ldb -lm -laud ...

Your programs need to include several header files that hold definitions (constants, macros, structures, library interfaces, and so forth) necessary to use the Digital UNIX security interfaces. Following traditional UNIX practice, all Digital UNIX system call and library reference pages denote the header files that you need to use their routines. You are likely to use the following individual header files, in the order listed:

<sys/secdefines.h>

Defines compilation constants that determine the security configuration of your system. You always need to include this file first.

<sys/security.h>

Holds general definitions. You almost always need to include this file.

<sys/acl.h>

For access control lists. You need this if you manipulate access control lists.

<prot.h>

Defines the authentication databases and Digital UNIX protected subsystems. You need these if your program accesses any of the authentication databases.

<sys/audit.h>

Defines the audit subsystem constants for security audit interfaces. You need this if you generate or process audit records.

<protcmd.h>

Provides a few miscellaneous definitions for trusted commands that are delivered with Digital UNIX. You seldom need these.

<sia.h>

SIA constants, structures, and macro definitions

<siad.h>

SIA constants, structures, and macro definitions internally used by the interfaces and security mechanisms

15.2    Standard Trusted System Directories

Digital UNIX defines several directories to hold its security information. You can review the reference pages for a description of these files and directories, primarily section 4.

You may need to create new files and directories in the standard trusted system directories. Generally, you should create new directories for the files you place in these trees. Do not simply insert new files in existing directories unless that directory was explicitly created for such files. Table 15-1 lists the directories you might use:

Table 15-1: Standard Trusted System Directories

15.3    System Calls and Library Routines with Enhanced Security

The tables in the following sections list many of the Digital UNIX system calls and library routines that have security implications for programmers.

Note that some system calls and library routines not covered in these sections might also have implicit security concerns.

The misuse of a system call or library routine that does not seem to have any security concerns could threaten the security of a computer system. For example, all system calls bypass file access permissions when called by a privileged process. Ultimately, programmers are responsible for the security implications of their programs.

15.3.1    System Calls

Table 15-2 lists the system calls that have security relevance for programmers.

Table 15-2: Security-Relevant System Calls

Table note:

*

These system calls can be called only by a privileged process or they may behave differently when called by a nonprivileged process. See the associated reference pages for more information.

15.3.2    Library Routines

Library routines are system services that programs can call. Many library routines use system calls. Table 15-3 lists Digital UNIX library routines that have security implications.

Table 15-3: Security-Relevant Library Routines

15.4    Defining the Trusted Computing Base

You must protect the trusted computing base (TCB) from unintended modification. To do this, you first define which of your programs and data files are a part of the TCB. The following list describes the components of the TCB:

• Trusted programs

  Any program that could subvert a security rule must be considered a trusted program. This includes programs that make direct security decisions, and those that do not but could subvert security if they contained errors or malicious code.

  Consider a program trusted if the program file has its user ID set to root (SUID).

• Indirect programs

  A program is trusted if another trusted program invokes it or otherwise interacts with it and depends upon its actions for security decisions. A program is also trusted if it modifies a data file or other object upon which another trusted program depends.

• Program files

  Executable files that contain a trusted program are considered a part of the TCB.

• Object code and libraries

  All object (binary) code modules and their files, whether statically or dynamically linked, that are included in a trusted program are part of the TCB. This includes the standard C library routines and interfaces, which are frequently used by trusted programs.

• Data files

  The TCB includes any file that contains data used by a trusted program to make a security decision, for example, the ttys database.

• Shell Scripts

  A shell script is a data file that a shell program interprets, performing the shell commands in the file. A shell script is considered part of the TCB if it performs a function on behalf of a trusted program or if it is needed for correct operation of the system. You can determine if a shell script is security relevant if removing or replacing the script would cause the system to perform improperly (for example, removing some of the rc startup scripts) or provide an opportunity for a security breach (installing a different cron startup file). Shell script files should be protected as carefully as object code program files. Note that a shell script must be readable to be executed.

• Antecedent directories

  Consider all parent directories of TCB files a part of the TCB and protect them accordingly. If malicious users can remove and redefine links in these directories, then they can create new, phony files that might cause a trusted program to make an incorrect security decision.

15.5    Protecting TCB Files

Each of the following mechanisms presents a way to protect the files and directories of the TCB:

• Discretionary access control (DAC)

  Discretionary access control (the owner, group, mode bits, and ACLs) is the most important protection for TCB files. It must prevent untrusted users and groups from modifying these files, although they might be allowed to read the files. It is common to create pseudo users and pseudo groups for this purpose.

• Read-only file systems

  You can place all files that only need to be read on a separate file system and mount that file system as read-only. This ensures that no program, no matter how privileged, can alter those files (at least short of remounting the file system). You can, of course, remount the file system as read/write if you need to alter the files. This is somewhat drastic but offers good protection against corruption of security data. You can also physically set a read-only locking tab on many kinds of removable media.

• Sticky bit

  Digital UNIX includes the sticky bit on directories. The sticky bit restricts the removal of directory entries (links) to those owned by the requesting user or the owner of the directory. Without this protection, programs only need write access to the directory. Use the sticky bit where appropriate, for example when a program needs to store files owned by different users in a single directory.