test

Trusted Solaris Administrator's Procedures

Preparing for User Accounts (Tasks)

To Modify Default User Label Attributes

When these changes are made while the system is being configured on the name service master, the files can be copied to each client computer as it is configured.

  1. Assume the Security Administrator role and go to an ADMIN_HIGH workspace.

  2. Review the default user attribute settings in the /etc/security/tsol/label_encodings file as shown in Table 3-1.

  3. Modify the user security attributes in the label_encodings file by using the Edit Label Encodings action from the System_Admin folder.

    The label_encodings file should be the same on all hosts.

  4. Distribute a copy of the file to every Trusted Solaris host.

    Follow the procedure in "(Optional) Copy Network Files to the /etc Directory" in Trusted Solaris Installation and Configuration.

To Modify policy.conf Defaults

When these changes are on the name service master, every user and role that is created inherits these values.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace. If you are using a name service, do this on the name service master.

  2. Review the default settings in the /etc/security/policy.conf file as shown in Table 3-2.

  3. Modify the settings in the policy.conf file by opening it in the Admin Editor and saving the new settings.

To Set Up Startup Files for Users

Users can put a .copy_files or .link_files into their home directory MLD at the SLD that corresponds to the minimum sensitivity label or can modify the files in the minimum label SLD if the files are already there. This procedure is for the administrator role to automate the setup for a site.

  1. Assume the System Administrator role and go to an ADMIN_LOW workspace. If you are using a name service, do this on the name service master.

  2. Set appropriate defaults for users in shell initialization files.

    For example, set the MANPATH to enable the users to access all Trusted Solaris man pages, and the LPDEST and PRINTER environment variables to send print jobs to a labeled printer.

    In a startup .cshrc file for users:


    setenv MANPATH /usr/dt/man:/usr/openwin/man:/usr/man
setenv PRINTER conf-label-gluten
setenv LPDEST  conf-label-gluten

    In a startup .ksh file for users:


    export MANPATH /usr/dt/man:/usr/openwin/man:/usr/man
export PRINTER conf-label-gluten
export LPDEST  conf-label-gluten

  3. Go to your directory of startup files for users.

    For example, 


    $ cd ~/startfiles_Cusers

  4. Copy the generic copies of startup files into a skeleton directory.

    The following example adds startup files for the mailer, the C shell, dtlogin, and dtterm.


    $ cp .cshrc .login .mailrc .Xdefaults .Xdefaults-hostname \ 
/etc/skelC

  5. Open the Admin Editor from the System_Admin folder in the Application Manager and enter the pathname to the .copy_files file, /etc/skelX/.copy_files.

    In the example, the pathname is /etc/skelC/.copy_files.

  6. Type into .copy_files, one file per line, the files to be copied into the user's home directory at all SLDs. Save and quit the file.

    Use Table 3-4 for ideas. For example,


    # .copy_files for regular users
# Copy these files to all home directory SLDs
.mailrc
.netscape
.soffice
:wq

  7. Repeat for .link_files -- create the file and type into it the files to be linked from the user's minimum-label home directory SLD to higher SLDs. Save and quit the file.

    Use Table 3-4 for ideas. In Step 4 the administrator placed site copies in the /etc/skelC directory. For example,


    # .link_files for regular users with C shells
# Link these files to all home directory SLDs
.cshrc
.login
.Xdefaults
.Xdefaults-hostname
:wq

To Invoke .login or .profile During Login

Note -

This procedure changes the default for all users on the host where the change is made.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. Use the File Manager or the command line to copy sys.dtprofile from /usr/dt/config to /etc/dt/config.

    Create the destination directory if it does not already exist.


    $ mkdir /etc/dt/config
$ cd /usr/dt/config
$ cp sys.dtprofile /etc/dt/config

  3. Use the Admin Editor action in the System_Admin folder to open the sys.dtprofile file for editing.

    See "To Edit a Local File", if needed.

  4. Remove the pound sign (#) before the DTSOURCEPROFILE variable assignment at the end of the file.

    After editing, the line should look like the following:


    DTSOURCEPROFILE=true

  5. Save and close the file.

  6. Distribute a copy of the file to every Trusted Solaris host that should have this change.

    Follow the procedure in "(Optional) Copy Network Files to the /etc Directory" in Trusted Solaris Installation and Configuration.

To Force dtterm to Launch New Shells as Login Shells

Do this procedure once for each home directory SLD at which the account works, or do it once in the home directory SLD at the account's minimum label, and then list the .Xdefaults-hostname in either .copy_files or .link_files, as described in "Using .copy_files and .link_files".

  1. Go to your home directory.

  2. Use a text editor to create or modify the .Xdefaults-hostname file.

  3. Add the following entry.


    Dtterm*LoginShell: true

  4. Write and quit the file.

  5. Log out and log back in to put the change into effect.

To Customize Shell Initialization Files for Users

  1. In the System Administrator role, follow the procedure to customize user initialization files in the section "Setting Up User Accounts Task Map" in System Administration Guide, Volume 1.

    The procedure tells you how to create three shell-specific skeleton directory names that are entered into the Skeleton path field when creating a user. The procedure also tells you to copy the local.login file to the skelC subdirectory, the local.profile file to the skelK subdirectory and the local.login file to the skelB subdirectory.

  2. Create a skelP subdirectory for users whose default shell is a profile shell.

  3. Create a .profile file and copy it into the skelP directory.

    See "Customizing a User's Work Environment" in System Administration Guide, Volume 1 for a discussion of what to include in initialization files.

  4. When creating user accounts or user templates, enter the appropriate skelX pathname into the Skeleton path field.

To Enable a User to Track Others' Jobs on a System

A Security Administrator might want to set up a server, such as an audit administration server, so that the main user of the server can monitor all at jobs and cron jobs running on the system.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. Open the Admin Editor from the System_Admin folder and type in the filename /etc/cron.d/cron.admin.

  3. Add the user's username to the list.

    The user is now enabled to track others' cron jobs on this system.

  4. Repeat for the file /etc/cron.d/at.admin, if the user is permitted to track other users' at jobs on this system.

  5. Check that the user has the Basic Solaris User profile.

    The Basic Solaris User profile includes the Edit Owned Jobs authorization.

To Enable a User to Track All Others' Jobs

The ability to monitor the cron and at jobs of other users is typically restricted to a role. However, the Security Administrator can assign an authorizations to enable a user to monitor others' jobs.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. Create a help file for the new right that you are about to create. Name it RtManageJobs.html, and provide it with text.

    For example, 


    <HTML>
<BODY>
<p>
This right allows users to manage other users' cronjobs and atjobs.
The user can modify cronjobs and atjobs using the Jobs Scheduler.
</BODY>
</HTML>

    See "To Create a Help File for a Rights Profile" for details of the steps.

  3. Launch the Solaris Management Console, and choose a toolbox in the appropriate scope. If you are using a name service, open the toolbox in the name service scope.

  4. Click the Users tool and supply a password when prompted.

  5. Double-click the Rights tool, and create a Custom_Manage_Jobs rights profile that contains the Manage All Jobs authorization.

    The Manage All Jobs authorization allows the account to add, modify or delete any user's job and to modify cron policies in the Job Scheduler tool of the SMC.

    See "To Create a Rights Profile" for the steps. Substitute the names and help text for your new profile in the procedure.

  6. Assign the right to the user by following the steps in "To Assign an Authorization to a User".