Skip Navigation Links | |
Exit Print View | |
Trusted Extensions Configuration and Administration Oracle Solaris 11.1 Information Library |
Part I Initial Configuration of Trusted Extensions
1. Security Planning for Trusted Extensions
2. Configuration Roadmap for Trusted Extensions
3. Adding the Trusted Extensions Feature to Oracle Solaris (Tasks)
4. Configuring Trusted Extensions (Tasks)
5. Configuring LDAP for Trusted Extensions (Tasks)
Part II Administration of Trusted Extensions
6. Trusted Extensions Administration Concepts
7. Trusted Extensions Administration Tools
8. Security Requirements on a Trusted Extensions System (Overview)
Configurable Security Features
Role Creation in Trusted Extensions
Role Assumption in Trusted Extensions
Trusted Extensions Interfaces for Configuring Security Features
Extension of Oracle Solaris Security Features by Trusted Extensions
Unique Trusted Extensions Security Features
Rules When Changing the Level of Security for Data
9. Performing Common Tasks in Trusted Extensions
10. Users, Rights, and Roles in Trusted Extensions (Overview)
11. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
12. Remote Administration in Trusted Extensions (Tasks)
13. Managing Zones in Trusted Extensions
14. Managing and Mounting Files in Trusted Extensions
15. Trusted Networking (Overview)
16. Managing Networks in Trusted Extensions (Tasks)
17. Trusted Extensions and LDAP (Overview)
18. Multilevel Mail in Trusted Extensions (Overview)
19. Managing Labeled Printing (Tasks)
20. Devices in Trusted Extensions (Overview)
21. Managing Devices for Trusted Extensions (Tasks)
22. Trusted Extensions Auditing (Overview)
23. Software Management in Trusted Extensions
Creating and Managing a Security Policy
Site Security Policy and Trusted Extensions
Computer Security Recommendations
Physical Security Recommendations
Personnel Security Recommendations
Additional Security References
B. Configuration Checklist for Trusted Extensions
Checklist for Configuring Trusted Extensions
C. Quick Reference to Trusted Extensions Administration
Administrative Interfaces in Trusted Extensions
Oracle Solaris Interfaces Extended by Trusted Extensions
Tighter Security Defaults in Trusted Extensions
Limited Options in Trusted Extensions
D. List of Trusted Extensions Man Pages
Trusted Extensions Man Pages in Alphabetical Order
Oracle Solaris Man Pages That Are Modified by Trusted Extensions
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 provide additional suggestions.
It is an unsafe practice to use email to instruct users to take an action.
Warn 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, 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 the shadow(4) man page.
auth_attr file – Contains custom authorizations. See the auth_attr(4) man page.
prof_attr file – Contains custom rights profiles. See the prof_attr(4) man page.
exec_attr file – Contains commands with security attributes that the site has added to rights profiles. See the exec_attr(4) man page.
Audit trail – Contains the audit records that the audit service has collected. See the audit.log(4) man page.
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 root. 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 name or user ID.