Skip Navigation Links | |
Exit Print View | |
Trusted Extensions Configuration and Administration Oracle Solaris 11 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)
9. Performing Common Tasks in Trusted Extensions (Tasks)
10. Users, Rights, and Roles in Trusted Extensions (Overview)
11. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
Customizing the User Environment for Security (Task Map)
How to Modify Default User Label Attributes
How to Modify policy.conf Defaults
How to Configure Startup Files for Users in Trusted Extensions
How to Log In to a Failsafe Session in Trusted Extensions
Managing Users and Rights (Task Map)
How to Modify a User's Label Range
How to Create a Rights Profile for Convenient Authorizations
How to Limit a User to Desktop Applications
How to Restrict a User's Set of Privileges
How to Prevent Account Locking for Users
How to Enable a User to Change the Security Level of Data
How to Delete a User Account From a Trusted Extensions System
12. Remote Administration in Trusted Extensions (Tasks)
13. Managing Zones in Trusted Extensions (Tasks)
14. Managing and Mounting Files in Trusted Extensions (Tasks)
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 (Reference)
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
In Trusted Extensions, you assume the Security Administrator role to administer users, authorizations, rights, and roles. The following task map describes common tasks that you perform for users who operate in a labeled environment.
|
You might want to extend a user's label range to give the user read access to an administrative application. For example, a user who can log in to the global zone could then view a list of the systems that run at a particular label. The user could view, but not change the contents.
Alternatively, you might want to restrict the user's label range. For example, a guest user might be limited to one label.
Before You Begin
You must be in the Security Administrator role in the global zone.
# usermod -K min_label=INTERNAL -K clearance=ADMIN_HIGH jdoe
You can also extend the user's label range by lowering the minimum label.
# usermod -K min_label=PUBLIC -K clearance=INTERNAL jdoe
For more information, see the usermod(1M) and user_attr(4) man pages.
# usermod -K min_label=INTERNAL -K clearance=INTERNAL jdoe
Where site security policy permits, you might want to create a rights profile that contains authorizations for users who can perform tasks that require authorization. To enable every user of a particular system to be authorized, see How to Modify policy.conf Defaults.
Before You Begin
You must be in the Security Administrator role in the global zone.
For the step-by-step procedure, see How to Create or Change a Rights Profile in Oracle Solaris Administration: Security Services.
The following authorizations that might be convenient for users:
solaris.device.allocate – Authorizes a user to allocate a peripheral device, such as a microphone or CD-ROM.
By default, Oracle Solaris users can read and write to a CD-ROM. However, in Trusted Extensions, only users who can allocate a device can access the CD-ROM drive. To allocate the drive for use requires authorization. Therefore, to read and write to a CD-ROM in Trusted Extensions, a user needs the Allocate Device authorization.
solaris.label.file.downgrade – Authorizes a user to lower the security level of a file
solaris.label.file.upgrade – Authorizes a user to heighten the security level of a file.
solaris.label.win.downgrade – Authorizes a user to select information from a higher-level file and place that information in a lower-level file.
solaris.label.win.noview – Authorizes a user to move information without viewing the information that is being moved.
solaris.label.win.upgrade – Authorizes a user to select information from a lower-level file and place that information in a higher-level file.
solaris.login.remote – Authorizes a user to remotely log in.
solaris.print.ps – Authorizes a user to print PostScript files.
solaris.print.nobanner - Authorizes a user to print hard copy without a banner page.
solaris.print.unlabeled – Authorizes a user to print hard copy that does not display labels.
solaris.system.shutdown – Authorizes a user to shut down the system and to shut down a zone.
For the step-by-step procedure, see How to Change the RBAC Properties of a User in Oracle Solaris Administration: Security Services.
Site security might require that users have access only to applications that they can open from a desktop icon. This procedure assigns rights profiles that limit users to required applications only.
Note - On the Trusted Extensions desktop, the execution of commands is always based on rights profiles.
To enable every user of a particular system to be so authorized, see How to Modify policy.conf Defaults.
Before You Begin
You must be in the Security Administrator role in the global zone.
For the procedure, see How to Restrict a User to Desktop Applications in Oracle Solaris Administration: Security Services.
The lines are wrapped for display purposes.
# profiles -p "Trusted Desktop Applets" profiles:Trusted Desktop Applets> set desc="Can use trusted desktop applications except terminal" profiles:Trusted Desktop Applets> add cmd=/usr/dt/config/tsoljds-migration;end profiles:Trusted Desktop Applets> add cmd=/usr/bin/tsoljds-xagent;end profiles:Trusted Desktop Applets> commit
You created this rights profile in Step 2.
profiles:Trusted Desktop Applets> add profiles="Desktop Applets" profiles:Trusted Desktop Applets> commit profiles:Trusted Desktop Applets> exit
Review the entries for errors, such as typos, omissions, or repetition.
# profiles -p "Trusted Desktop Applets" info Found profile in files repository. name=Trusted Desktop Applets desc=Can use trusted desktop applications except terminal profiles=Desktop Applets cmd=/usr/dt/config/tsoljds-migration cmd=/usr/bin/tsoljds-xagent
Tip - You can create a rights profile for an application or a class of applications that have desktop icons. Then, add the Trusted Desktop Applets rights profile as a supplementary rights profile for desktop access.
# usermod -P "Trusted Desktop Applets,Stop" username
This user can use the trusted desktop, but cannot launch a terminal window, act as the Console User, or have any of the rights contained in the Basic Solaris User rights profile.
Example 11-5 Enabling a Desktop User to Open a Terminal Window
In this example, the administrator enables a desktop user to open a terminal window. The administrator has already created the Desktop Applets rights profile for Oracle Solaris desktop users and the Trusted Desktop Applets rights profile for Trusted Extensions desktop users in the LDAP repository.
First, the administrator creates the Terminal Window rights profile and verifies its contents.
# profiles -p "Terminal Window" -S ldap profiles:Terminal Window> set desc="Can open a terminal window" profiles:Terminal Window> add cmd=/usr/bin/gnome-terminal;end profiles:Terminal Window> commit profiles:Terminal Window> exit # profiles -p "Terminal Window" info Found profile in ldap repository. name=Terminal Window desc=Can open a terminal window cmd=/usr/bin/gnome-terminal
Then, the administrator assigns this rights profile and the All rights profile to desktop users who require terminal windows to perform their tasks. Without the All rights profile, users would not be able to run UNIX commands that do not require privilege, such as ls and cat.
# usermod -P "Trusted Desktop Applets,Terminal Window,All,Stop" -S ldap jdoe
With this set of rights profiles, user jdoe can use the desktop and terminal windows, but cannot act as the Console User or have any of the rights contained in the Basic Solaris User rights profile.
Site security might require that users be permitted fewer privileges than users are assigned by default.
Before You Begin
You must be in the Security Administrator role in the global zone.
Caution - Do not remove the proc_fork or the proc_exec privilege. Without these privileges, a user cannot use the system. |
# usermod -K defaultpriv=basic,!proc_info,!proc_session,!file_link_any
By removing the proc_info privilege, you prevent the user from examining any processes that do not originate from the user. By removing the proc_session privilege, you prevent the user from examining any processes outside the user's current session. By removing the file_link_any privilege, you prevent the user from making hard links to files that are not owned by the user.
See Also
For an example of collecting the privilege restrictions in a rights profile, see the examples following How to Create or Change a Rights Profile in Oracle Solaris Administration: Security Services.
To restrict the privileges of all users on a system, see Example 11-2.
Perform this procedure for all users who can assume a role.
Before You Begin
You must be in the Security Administrator role in the global zone.
# usermod -K lock_after_retries=no jdoe
To turn off account locking for an LDAP user, specify the LDAP repository.
# usermod -S ldap -K lock_after_retries=no jdoe
A regular user or a role can be authorized to change the security level, or labels, of files and directories or of selected text. The user or role, in addition to having the authorization, must be configured to work at more than one label. And, the labeled zones must be configured to permit relabeling. For the procedure, see How to Enable Files to Be Relabeled From a Labeled Zone.
Caution - Changing the security level of data is a privileged operation. This task is for trustworthy users only. |
Before You Begin
You must be in the Security Administrator role in the global zone.
The following authorizations enable a user to relabel a file:
Downgrade File Label
Upgrade File Label
The following authorizations enable a user to relabel information within a file:
Downgrade DragNDrop or CutPaste Info
DragNDrop or CutPaste Info Without Viewing
Upgrade DragNDrop or CutPaste Info
For a step-by-step procedure, see How to Change the RBAC Properties of a User in Oracle Solaris Administration: Security Services.
When a user is removed from the system, you must ensure that the user's home directory and any objects that the user owns are also deleted. As an alternative to deleting objects that are owned by the user, you might change the ownership of these objects to a valid user.
You must also ensure that all batch jobs that are associated with the user are also deleted. No objects or processes belonging to a removed user can remain on the system.
Before You Begin
You must be in the System Administrator role in the global zone.
# userdel -r jdoe
Note - You are responsible for finding and deleting the user's temporary files at all labels, such as files in /tmp directories.
For further considerations, see User Deletion Practices.