|Skip Navigation Links|
|Exit Print View|
|Trusted Extensions Configuration and Administration Oracle Solaris 11.1 Information Library|
The following task map describes common tasks that you can perform when customizing a system for all users, or when customizing an individual user's account. Many of these tasks are performed before regular users can log in.
You can modify the default user label attributes during the configuration of the first system. The changes must be copied to every Trusted Extensions system.
Caution - You must complete this task before any regular users access the system.
Before You Begin
You must be in the Security Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.
Caution - The label_encodings file must be the same on all systems. For one distribution method, see How to Copy Files to Portable Media in Trusted Extensions and How to Copy Files From Portable Media in Trusted Extensions.
Changing the policy.conf defaults in Trusted Extensions is identical to changing any security-relevant system file in Oracle Solaris. Use this procedure to change the defaults for all users of a system.
Before You Begin
You must be in the root role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.
For Trusted Extensions keywords, see Table 10-1.
Example 11-1 Changing the System's Idle Settings
In this example, the security administrator wants idle systems to return to the login screen. The default locks an idle system. Therefore, the root role adds the IDLECMD keyword=value pair to the /etc/security/policy.conf file as follows:
The administrator also wants systems to be idle a shorter amount of time before logout. Therefore, the root role adds the IDLETIME keyword=value pair to the policy.conf file as follows:
The system now logs out the user after the system is idle for 10 minutes.
Note that if the login user assumes a role, the user's IDLECMD and IDLETIME values are in effect for that role.
Example 11-2 Modifying Every User's Basic Privilege Set
In this example, the security administrator of a large Sun Ray installation does not want regular users to view the processes of other Sun Ray users. Therefore, on every system that is configured with Trusted Extensions, the root role removes proc_info from the basic set of privileges. The PRIV_DEFAULT setting in the /etc/policy.conf file is uncommented and modified as follows:
Example 11-3 Assigning Printing-Related Authorizations to All Users of a System
In this example, site security permits a public kiosk computer to print without labels. On the public kiosk, the root role modifies the value for AUTHS_GRANTED in the /etc/security/policy.conf file. At the next boot, print jobs by all users of this kiosk print without page labels.
Then, the administrator decides to save paper by removing banner and trailer pages. The administrator further modifies the policy.conf entry.
After the public kiosk is rebooted, all print jobs are unlabeled, and have no banner or trailer pages.
Users can put a .copy_files file and .link_files file into their home directory at the label that corresponds to their minimum sensitivity label. Users can also modify the existing .copy_files and .link_files files at the users' minimum label. This procedure is for the administrator role to automate the setup for a site.
Before You Begin
You must be in the System Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.
You are going to add .copy_files and .link_files to your list of startup files.
# cd /etc/skel # touch .copy_files .link_files
For a discussion of which files to include in startup files, see Customizing a User’s Work Environment in Managing User Accounts and User Environments in Oracle Solaris 11.1.
The P indicates the Profile shell.
The X indicates the letter that begins the shell's name, such as B for Bourne, K for Korn, C for a C shell, and P for Profile shell.
Example 11-4 Customizing Startup Files for Users
In this example, the system administrator configures files for every user's home directory. The files are in place before any user logs in. The files are at the user's minimum label. At this site, the users' default shell is the C shell.
The system administrator creates a .copy_files and a .link_files file with the following contents:
## .copy_files for regular users ## Copy these files to my home directory in every zone .mailrc .mozilla .soffice :wq
## .link_files for regular users with C shells ## Link these files to my home directory in every zone .bashrc .bashrc.user .cshrc .login :wq
## .link_files for regular users with Korn shells # Link these files to my home directory in every zone .ksh .profile :wq
In the shell initialization files, the administrator ensures that the users' print jobs go to a labeled printer.
## .cshrc file setenv PRINTER conf-printer1 setenv LPDEST conf-printer1
## .ksh file export PRINTER conf-printer1 export LPDEST conf-printer1
The customized files are copied to the appropriate skeleton directory.
$ cp .copy_files .link_files .bashrc .bashrc.user .cshrc \ .login .profile .mailrc /etc/skelC $ cp .copy_files .link_files .ksh .profile .mailrc \ /etc/skelK
If you create a .copy_files files at your lowest label, then log in to a higher zone to run the updatehome command and the command fails with an access error, try the following:
Verify that from the higher-level zone you can view the lower-level directory.
higher-level zone# ls /zone/lower-level-zone/home/username ACCESS ERROR: there are no files under that directory
If you cannot view the directory, then restart the automount service in the higher-level zone:
higher-level zone# svcadm restart autofs
Unless you are using NFS mounts for home directories, the automounter in the higher-level zone should be loopback mounting from /zone/lower-level-zone/export/home/username to /zone/lower-level-zone/home/username.
In Trusted Extensions, failsafe login is protected. If a regular user has customized shell initialization files and now cannot log in, you can use failsafe login to fix the user's files.
Before You Begin
You must know the root password.
You can now debug the user's initialization files.