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.
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:
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:
Directory | Contents |
/tcb/bin /usr/tcb/bin | Contains directly executed trusted commands and daemons. |
/tcb/lib | Contains programs that are run by other trusted programs but are never invoked from the command line. |
/tcb/files | Contains control files, databases, and scripts used by the trusted computing base (TCB). You can define a subdirectory of this directory for your protected subsystem, if necessary. |
/var/tcb | Alternative to the /tcb directory. |
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.
Table 15-2 lists the system calls that have security relevance for programmers.
Category | System Calls |
File control | creat, open, fcntl, read, mknod*, write |
Process control | fork, sigpause, execve, sigsetmask, setpgrp*, sigvec, sigblock |
File attributes | access, chroot*, chmod*, stat, chown*, umask |
User and group ID | getegid, getuid, getgid, setgroups*, geteuid, setreuid* |
Auditing | audcntl*, audgen* |
General | syscall |
Table note:
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.
Category | Library Routines |
File control | fopen, popen |
Password handling | getpass, putpwent, getpwnam, setpwent, getpwent, endpwent, getpwuid, passlen, pw_mapping, randomword, time_lock |
Process control | signal |
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:
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).
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.
Executable files that contain a trusted program are considered a part of the TCB.
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.
The TCB includes any file that contains data used by a trusted program to make a security decision, for example, the ttys database.
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.
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.
Each of the following mechanisms presents a way to protect the files and directories of the TCB:
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.
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.
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.