This chapter describes the implication of running trusted applications on a trusted Tru64 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,
libaud.so,
libacl.a,
and the
libacl.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 Tru64 UNIX security interfaces. Following traditional UNIX practice, all Tru64 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 Tru64 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 Tru64 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
Tru64 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 Tru64 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:
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.
Library routines are system services that programs can call. Many library routines use system calls. Table 15-3 lists Tru64 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:
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) or ifit has any granted or potential privilege (systems supporting file-based privileges)
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.
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. It is somewhat safer to use only the mode bits for protection, as opposed to an access control list (ACL).
Because ACLs are a new feature, existing programs may copy only the mode bits when replicating a file and therefore accidentally delete the ACL. This removes the protection offered by the ACL. The best way to avoid these accidents is to use only the mode bits. See Chapter 21.
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: Tru64 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.
Tru64 UNIX provides a Security Integration Architecture (SIA) which
allows the layering of local and distributed security authentication mechanisms
onto the operating system.
The SIA configuration framework isolates security
sensitive commands from the specific security mechanisms.
See the
Using the SIA Interface
chapter of the
Security
manual
and the
sia*(3)
reference pages for more information.
The Programmer's Guide to Security portion of the Security manual also provides detailed information on all aspects of creating trusted programs.