NAME | DESCRIPTION | COMMAND SYNTAX | Rules for the Display and Entering of Labels | EXAMPLES | TRUSTED SOLARIS DIFFERENCES | SUMMARY OF TRUSTED SOLARIS CHANGES | ATTRIBUTES | SEE ALSO | DIAGNOSTICS | NOTES
This section describes Trusted SolarisTM commands that are used chiefly for system maintenance and administration. The Trusted Solaris environment includes the following commands:
Commands that are unique to and originate in the Trusted Solaris environment, such as adminvi(1M), which enables administrators and other users to edit files while preventing certain vi actions that present a security risk.
SunOS
5.8 commands that have been modified to work within the Trusted Solaris security policy, such as mount(1M). Man pages for modified
commands have been rewritten to remove information that is not accurate for how the command behaves within the Trusted Solaris environment. Modified man pages also add descriptions for any new features, options, and arguments.
SunOS
5.8 commands that remain unchanged from the Solaris 8 release, such as ln.
Because of command restructuring for the Virtual File System architecture, there are several instances of multiple manual pages that begin with the same name. For example, there are multiple mount pages - mount(1M), mount_hsfs(1M), mount_nfs(1M), mount_tmpfs(1M), and mount_ufs(1M). In each such case the first of the multiple pages describes the syntax and options of the generic command, that is, those options applicable to all FSTypes (file system types). The succeeding pages describe the functionality of the FSType-specific modules of the command. These pages list the command followed by an underscore ( _ ) and the FSType to which they pertain. Note that the administrator should not attempt to call these modules directly. The generic command provides a common interface to all of them. Thus the FSType-specific manual pages should not be viewed as describing distinct commands, but rather as detailing those aspects of a command that are specific to a particular FSType.
Unless otherwise noted, commands described in this section accept options and other arguments according to the following syntax:
name [option(s)] [cmdarg(s)]
The name of an executable file.
- noargletter(s) or,
- argletter< >optarg
where < > is optional white space.
A single letter representing an option without an argument.
A single letter representing an option requiring an argument.
Argument (character string) satisfying preceding argletter.
Pathname (or other command argument) not beginning with - or, - by itself indicating the standard input.
When entering labels on the command line in a UNIX shell, follow these rules. For rules for entering labels in graphical user interfaces, see Rules for the Display and Entering of Labels. For rules for entering labels in configuration files, see RULES FOR INCLUDING LABELS IN A CONFIGURATION FILE in Intro(4).
Enter a sensitivity label (SL) or clearance, in text in the form:
{ + } { classification } { { +|- }word } … |
The system always displays labels in uppercase. Users may enter labels in any combination of uppercase and lowercase.
The classification part of the label must be a valid classification name as defined in label_encodings(4). Classification names may contain embedded blanks or punctuation, if they are so defined in label_encodings. Short and long forms of classification names may be used interchangeably.
The words (compartments and markings) used in labels must be valid words as defined in label_encodings. Words may contain embedded blanks or punctuation if they are so defined in label_encodings.
Short and long forms of words may be used interchangeably. Words may be specified in any order; however they are processed left to right, so that where words conflict with each other, the word furthest to the right takes precedence.
You may use plus and minus signs when modifying an existing label to turn on or off the compartments and markings associated with the words.
A CMW label is represented in text in the form:
ADMIN_LOW [ SENSITIVITY_LABEL ] |
Items in curly brackets are optional. Leading and trailing white space is ignored. Items may be separated by blanks, tabs, commas, or slashes (/).
On the command line, enclose any label with more than one word in double quotes because, without quotes, a second word or letter separated by a space is interpreted as a second argument. Enclose labels containing [ and ] characters in quotes to suppress the shell's use of those characters in filename substitution.
$ setlabel "[ts a b]" somefile $ setlabel "[ts,a,b]" somefile $ setlabel "[ts/a b]" somefile |
Use any combination of upper and lowercase letters. You may separate items in a label with blanks, tabs, commas or slashes (/). Do not use any other punctuation.
$ setlabel -s SECRET somefile |
When entering an SL with a command option that sets the SL, you do not need to use brackets around the SL.
$ setlabel -s "TOP SECRET A B" somefile |
To set somefile's SL to SECRET A.
$ setlabel "[Secret a]" somefile |
To turn on compartment B in somefile's SL.
$ setlabel -s +b somefile |
To turn off compartment A in somefile's SL.
$ setlabel -s -A somefile |
The responsibilities and privileges of the superuser have been divided among several administrative roles. When a man page that has not been modified for the Trusted Solaris system states that superuser is required to execute a certain command or option, remember that one or more privileges are required instead. The site's security administrator can perform privilege debugging [see runpd(1M)] to find out which privileges are needed and can then decide to give the privilege to the command after assessing whether the command and any users set up to use that command can make use of the privilege in a manner that does not violate the site's security policy.
The ability of the UNIX superuser to bypass access restrictions, to execute restricted commands, and to use some command options not available to other users has been replaced with the profile mechanism, which allows the security administrator to assign to various users different
sets of commands and to assign different privileges to the commands using rights profiles. When a command or one of its options needs a privilege in order to succeed, that privilege is a required privilege; if the required privilege is not given to the command in a user's rights profile by the security administrator, the command will not work. Required privileges are indicated on
the man page with the words “must have”, as shown in this sentence: “The ifconfig(1M) command must have the sys_net_config
privilege
to modify network interfaces.”
In other cases, when the command is designed to work within security policy and it fails when certain DAC or MAC checks are not passed, an override privilege may be assigned at the security administrator's discretion. On man pages, the names of privileges that may be used to override access restrictions are given in the ERRORS section. The override privileges that may be given to bypass DAC or MAC restrictions on files or directories are given below:
The DAC override privileges are file_dac_read
and file_dac_write
. If a user does not have DAC access to a file, the security administrator may assign one or both of these privileges
to the command, depending on whether read or write access or both are desired. The MAC override privileges are file_mac_read
and file_mac_write
. If a user does not have MAC access
to a file, the security administrator may assign one or both of these privileges to the command, depending on whether read or write access or both are desired.
Besides being able to assign an override privilege, the security administrator has other options. For example, to avoid the use of privilege the security administrator may specify that the command will execute with another user's ID (usually the root ID 0) or group ID, one that allows access to the file or directory based on its permissions or its ACL.
To find out how privileges are made available to commands and to find out exactly which tasks, commands, and privileges are assigned to each of the roles by means of rights profiles shipped with the default system, see Trusted Solaris Administrator's Procedures.
Also, check with your security administrator to find out which roles are configured at your site and if any of the roles have been reconfigured to suit your site's security policy.
Besides the usual UNIX DAC checks performed when a process acting on behalf of a user attempts to access a file or directory, mandatory access checks also must be passed. For each possible type of access failure, a specific override privilege may be assigned to the command at the security administrator's discretion.
The printed Trusted Solaris 8 HW 12/02 Reference Manual contains only the Trusted Solaris original and modified (from the Solaris environment) man pages. The online set of man pages viewed by the man command accesses all man pages; AnswerBook2TM can access all man pages in the AnswerBook2 collections. For a fuller description, see Trusted Solaris Manual Page Display in Intro(1). The SEE ALSO man page heading has been subdivided to help users of the printed manual locate a referenced man page.
When a SUMMARY OF TRUSTED SOLARIS CHANGES is provided on a modified man page, it is intended as a convenience to summarize for you the major changes all in one place. Do not rely on the SUMMARY OF TRUSTED SOLARIS CHANGES alone, but also read the entire man page.
See attributes(5) in the SunOS 5.8 Reference Manual for a discussion of the attributes listed in this section.
Commands that are listed under the Trusted Solaris 8 HW 12/02 Reference Manual heading in the SEE ALSO section are commands that have been changed or added in the Trusted Solaris environment. Commands that are listed under the SunOS 5.8 Reference Manual heading in the SEE ALSO section are commands that are unchanged in the Trusted Solaris environment. If you are using printed manuals, refer to the SunOS 5.8 Reference Manual for Solaris commands that are unchanged in the Trusted Solaris environment.
Upon termination, each command returns 0 for normal termination and non-zero to indicate troubles such as erroneous parameters, bad or inaccessible data, or other inability to cope with the task at hand. It is called variously ``exit code,'' ``exit status,'' or ``return code,'' and is described only where special conventions are involved.
Unfortunately, not all commands adhere to the standard syntax.
NAME | DESCRIPTION | COMMAND SYNTAX | Rules for the Display and Entering of Labels | EXAMPLES | TRUSTED SOLARIS DIFFERENCES | SUMMARY OF TRUSTED SOLARIS CHANGES | ATTRIBUTES | SEE ALSO | DIAGNOSTICS | NOTES