15 Introduction for Programmers

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.

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.so, libaud.a, libaud.so, libpacl.a, and the libpacl.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

15.2 Standard Trusted System Directories

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 the section 4 reference pages.

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

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.

15.3 Security Relevent System Calls and Library Routines

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.

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

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.

15.3.2 Library Routines

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.

Table 15-3: Security-Relevant Library Routines

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`

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.
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. Compaq recommends that you use restrictive traditional permissions, such as other::--- and group::---, and then grant access to individual users with user entries. Using this approach, if an ACL is lost, unintended access is not allowed. See Chapter 21 for information on programming with ACLs.

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.

15.5.1 Secure Applications

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.