NAME | DESCRIPTION | TRUSTED SOLARIS DIFFERENCES | RULES FOR INCLUDING LABELS IN A CONFIGURATION FILE | POLICY FOR SECURITY ATTRIBUTES ON CONFIGURATION FILES | SEE ALSO |
This section outlines the formats of various files. The C structure declarations for the file formats are given where applicable. Usually, the headers containing these structure declarations can be found in the directories /usr/include or /usr/include/sys. For inclusion in C language programs, however, the syntax #include <filename.h> or #include <sys/filename.h> should be used.
Because the operating system now allows the existence of multiple file system types, there are several instances of multiple manual pages with the same name. These pages all display the name of the FSType to which they pertain, in the form name_fstype at the top of the page. For example, fs_ufs(4).
In the Trusted Solaris environment, these configuration files can be:
Files that are unique to and originate in the Trusted Solaris environment, such as device_allocate(4).
SunOS
5.8 configuration files that have been modified to work within Trusted Solaris
security policy, such as proc(4). Man
pages for modified files have been rewritten to remove information that
is not accurate for how the file is used within the Trusted Solaris environment.
Modified man pages also add descriptions for new fields or entities.
SunOS
5.8 files that remain unchanged from the Solaris 8 release, such as timezone(4).
The printed Trusted Solaris 8 Reference Manual includes only those files
that have been modified or originate in the Trusted Solaris environment.
Printed versions of unchanged SunOS
5.8 man pages are found in the SunOS 5.8 Reference Manual. For more
information on displaying manual pages, see Trusted Solaris Manual Page Display in Intro(1).
The Trusted Solaris operating environment is a security-enhanced version of the Solaris operating environment, the Common Desktop Environment (CDE), the X window system, and the Solstice AdminSuite set of system administration tools. To preserve security attributes, configuration files are usually not edited using vi or another common editor. Rather, administrative roles edit the files using administrative GUIs. The GUIs audit all changes and preserve the required owner, group, permissions and sensitivity labels of the files.
Follow the rules described here when entering labels in configuration files. When entering labels in graphical user interfaces, see Rules for the Display and Entering of Labels in Intro(1). When entering labels on the command line in a UNIX shell, follow the rules in Rules for the Display and Entering of Labels in Intro(1M).
Make sure that a program reading a configuration file can tell where the label starts and ends. Where the label is imbedded, as it is in the device_allocate(4) file, the only valid character to begin the label and terminate it is a semicolon (;). Most configuration files do not support label incrementations using plus or minus signs.
Configuration files are generally maintained at a sensitivity label
of ADMIN_LOW
. However, each site
can choose whether to store labels in configuration files as text or as
hexadecimal numbers, depending on the site's security policy, and the form
used affects the sensitivity label at which the file should be stored. When
labels are stored in human-readable form, the files that contain them must
be protected at ADMIN_HIGH
, so
only administrative roles that have the ADMIN_HIGH
label in their clearance can view the files. Also, if a file
contains a collection of data written by all processes in the system (like
the system log, /dev/kmem, and /dev/mem
files) that file should be protected at the ADMIN_HIGH
sensitivity label.
Labels entered in text form must be quoted.
The default user and group for configuration files are root and sys and default permissions are 00644. However, the security administrator should ensure that files that contain sensitivity information other than labels, such as those files that specify which activities are being audited, are not generally readable. These files should have more restrictive permissions, owner and group IDs, and possibly a protective label.
Description
Audit trail file
Audit class definitions
Control information for system audit daemon
Current information on audit daemon
Audit event definition and class mapping file
Per-user auditing data file
Descriptions of defined authorizations
Authorization description database
List of window privileges that override system checks
Device allocate information file
Device deallocate file
Maps allocatable devices to device special files
device policy file
execution attributes database
See logindevperm(4)
Internet servers database
Script for init
Label encodings file
login-based device permissions
Mounted file system table
the NCA configuration file that specifies physical interfaces
Configuration file for the name service switch
Configuration file for security policy
Descriptions of defined privileges
Privilege description database
/proc, the process file system
profile description database
Configuration file for name server routines
Remote mounted file system table
Selection rules for copy, cut, paste, drag and drop operations
shadow password file
Shared file system table
Log of tnd debugging information
Trusted network interface-control database
Trusted network remote-host database
Trusted network remote-host templates
Static routing configuration file
Package security-attribute description file
User profiles database
User security attributes database
extended user attributes database
Table of file system defaults
Attribute data file for mounting a file system
NAME | DESCRIPTION | TRUSTED SOLARIS DIFFERENCES | RULES FOR INCLUDING LABELS IN A CONFIGURATION FILE | POLICY FOR SECURITY ATTRIBUTES ON CONFIGURATION FILES | SEE ALSO |