1. Trusted Extensions Administration Concepts
2. Trusted Extensions Administration Tools
3. Getting Started as a Trusted Extensions Administrator (Tasks)
4. Security Requirements on a Trusted Extensions System (Overview)
Configurable Oracle Solaris Security Features
Trusted Extensions Interfaces for Configuring Security Features
Extension of Oracle Solaris Security Mechanisms by Trusted Extensions
Trusted Extensions Security Features
Rules When Changing the Level of Security for Data
Customization of Solaris Trusted Extensions (CDE)
5. Administering Security Requirements in Trusted Extensions (Tasks)
6. Users, Rights, and Roles in Trusted Extensions (Overview)
7. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
8. Remote Administration in Trusted Extensions (Tasks)
9. Trusted Extensions and LDAP (Overview)
10. Managing Zones in Trusted Extensions (Tasks)
11. Managing and Mounting Files in Trusted Extensions (Tasks)
12. Trusted Networking (Overview)
13. Managing Networks in Trusted Extensions (Tasks)
14. Multilevel Mail in Trusted Extensions (Overview)
15. Managing Labeled Printing (Tasks)
16. Devices in Trusted Extensions (Overview)
17. Managing Devices for Trusted Extensions (Tasks)
18. Trusted Extensions Auditing (Overview)
19. Software Management in Trusted Extensions (Tasks)
A. Quick Reference to Trusted Extensions Administration
To ensure that the security of the system is not compromised, administrators need to protect passwords, files, and audit data. Users need to be trained to do their part. To be consistent with the requirements for an evaluated configuration, follow the guidelines in this section.
Each site's security administrator ensures that users are trained in security procedures. The security administrator needs to communicate the following rules to new employees and remind existing employees of these rules on a regular basis:
Do not tell anyone your password.
Anyone who knows your password can access the same information that you can without being identified and therefore without being accountable.
Do not write your password down or include it in an email message.
Choose passwords that are hard to guess.
Do not send your password to anyone by email.
Do not leave your computer unattended without locking the screen or logging off.
Remember that administrators do not rely on email to send instructions to users. Do not ever follow emailed instructions from an administrator without first double-checking with the administrator.
Be aware that sender information in email can be forged.
Because you are responsible for the access permissions on files and directories that you create, make sure that the permissions on your files and directories are set appropriately. Do not allow unauthorized users to read a file, to change a file, to list the contents of a directory, or to add to a directory.
Your site might want to provide additional suggestions.
It is an unsafe practice to use email to instruct users to take an action.
Tell users not to trust email with instructions that purport to come from an administrator. Doing so prevents the possibility that spoofed email messages could be used to fool users into changing a password to a certain value or divulging the password, which could subsequently be used to log in and compromise the system.
The System Administrator role must specify a unique user name and user ID when creating a new account. When choosing the name and ID for a new account, the administrator you must ensure that both the user name and associated ID are not duplicated anywhere on the network and have not been previously used.
The Security Administrator role is responsible for specifying the original password for each account and for communicating the passwords to users of new accounts. You must consider the following information when administering passwords:
Make sure that the accounts for users who are able to assume the Security Administrator role are configured so that the account cannot be locked. This practice ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if all other accounts are locked.
Communicate the password to the user of a new account in such a way that the password cannot be eavesdropped by anyone else.
Change an account's password if you have any suspicion that the password has been discovered by someone who should not know it.
Never reuse user names or user IDs over the lifetime of the system.
Ensuring that user names and user IDs are not reused prevents possible confusion about the following:
Which actions were performed by which user when audit records are analyzed
Which user owns which files when archived files are restored
You as an administrator are responsible for correctly setting up and maintaining discretionary access control (DAC) and mandatory access control (MAC) protections for security-critical files. Critical files include the following:
shadow file – Contains encrypted passwords. See shadow(4).
prof_attr database – Contains definitions of rights profiles. See prof_attr(4).
exec_attr database – Contains commands and actions that are part of rights profiles. See exec_attr(4).
user_attr file – Contains the rights profiles, privileges, and authorizations that are assigned to local users. See user_attr(4).
Audit trail – Contains the audit records that the auditing service has collected. See audit.log(4)
![]() | Caution - Because the protection mechanisms for LDAP entries are not subject to the access control policy enforced by the Trusted Extensions software, the default LDAP entries must not be extended, and their access rules must not be modified. |
In local files, passwords are protected from viewing by DAC and from modifications by both DAC and MAC. Passwords for local accounts are maintained in the /etc/shadow file, which is readable only by superuser. For more information, see the shadow(4) man page.
The System Administrator role needs to verify on the local system and on the network that all groups have a unique group ID (GID).
When a local group is deleted from the system, the System Administrator role must ensure the following:
All objects with the GID of the deleted group must be deleted or assigned to another group.
All users who have the deleted group as their primary group must be reassigned to another primary group.
When an account is deleted from the system, the System Administrator role and the Security Administrator role must take the following actions:
Delete the account's home directories in every zone.
Delete any processes or jobs that are owned by the deleted account:
Delete any objects that are owned by the account,or assign the ownership to another user.
Delete any at or batch jobs that are scheduled on behalf of the user. For details, see the at(1) and crontab(1) man pages.
Never reuse the user (account) name or user ID.