Go to main content

Securing Users and Processes in Oracle® Solaris 11.4

Exit Print View

Updated: September 2018
 
 

Assigning Rights to Applications and Scripts

Applications and scripts execute one command or a series of commands. To assign rights, you set the security attributes, such as set IDs or privileges, for each command in a rights profile. Applications can check for authorizations, if appropriate.


Note -  If a command in a script needs to have the setuid bit or setgid bit set to succeed, the script executable and the command must have the security attributes added in a rights profile. When the script is executed in a profile shell, the command runs with the security attributes.

How to Run a Shell Script With Privileged Commands

To run a privileged shell script, you add privileges to the script and to the commands in the script. Then, the appropriate rights profile must contain the commands with privileges assigned to them.

Before You Begin

You must assume the root role. For more information, see Using Your Assigned Administrative Rights.

  1. Create the script with /bin/pfsh, or any other profile shell, on the first line.
    #!/bin/pfsh
    # Copyright (c) 2015 by Oracle
  2. As a regular user, determine the privileges that the commands in the script need.

    By running the script with no privileges, the debug option to the ppriv command lists the missing privileges.

    $ ppriv -eD script-full-path

    For more information, see How to Determine Which Privileges a Program Requires.

  3. Create or modify a rights profile for the script.

    Add the shell script, and the commands in the shell script, with their required security attributes to the rights profile. See How to Create a Rights Profile.

  4. Assign the rights profile to a trusted user or role.

    For examples, see Assigning Rights to Users.

  5. To run the script, do one of the following:
    • If you are assigned the script as a user, open a profile shell and run the script.
      $ pfexec script-full-path
    • If you are assigned the script as a role, assume the role and run the script.
      $ su - rolename
      Password: xxxxxxxx
      # script-full-path
Example 38  Assigning Security Attributes to a Legacy Application

Because a legacy application is not privilege-aware, the administrator assigns the euid=0 security attribute to the application executable in a rights profile. Then, the administrator assigns it to a trusted user.

# profiles -p LegacyApp
profiles:LegacyApp> set desc="Legacy application"
profiles:LegacyApp> add cmd=/opt/legacy-app/bin/legacy-cmd
profiles:LegacyApp:legacy-cmd> set euid=0
profiles:LegacyApp:legacy-cmd> end
profiles:LegacyApp> exit
# profiles -p LegacyApp 'select cmd=/opt/legacy-app/bin/legacy-cmd;info;end'
	id=/opt/legacy-app/bin/legacy-cmd
	euid=0
# usermod -K profiles+="Legacy application" jdoe
Example 39  Running an Application With Assigned Rights

In this example, the administrator assigns the rights profile from Example 49, Creating a Rights Profile That Includes Privileged Commands to a trusted user. The user must provide a password when executing the script.

# usermod -K auth_profiles+="Site application" jdoe
Example 40  Checking for Authorizations in a Script or Program

To check for authorizations, write a test that is based on the auths command. For detailed information about this command, see the auths(1) man page.

For example, the following line tests whether the user has the authorization that is supplied as the $1 argument:

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

    A more complete test includes logic that checks for the use of wildcards. For example, to test whether the user has the solaris.system.date authorization, you would need to check for the following strings:

  • solaris.system.date

  • solaris.system.*

  • solaris.*

If you are writing a program, use the function getauthattr() to test for the authorization.

Example 41  Scripting the Batch Editing of Files in a Directory

This example shows how to batch edit sensitive files by using two scripts. The first script switches out the default editor and calls the second script. The second script is the editing script. By changing the second script, you keep a record of the changes to the files.

  1. Create the first script.

    # pfedit batchpfedit.sh
        #!/usr/bin/bash
        OLDEDITOR=$EDITOR
        export EDITOR=~/bin/key-edit.sh
        pfedit /var/ITdemos/firstdemo-directory
        export EDITOR=$OLDEDITOR

    Where:

    OLDEDITOR=$EDITOR

    Defines the OLDEDITOR variable to hold the value of the current editor.

    ~/bin/key-edit.sh

    Is the script that contains the edits.

    pfedit /var/ITdemos/firstdemo-directory

    Is the command that creates a temporary pfedit file for the script to use.

    export EDITOR=$OLDEDITOR

    Replaces the original $EDITOR definition.

  2. Create the editing script.

    # pfedit batchpfedit.sh
        #!/usr/bin/bash
        OLDEDITOR=$EDITOR
        export EDITOR=~/bin/key-edit.sh
        pfedit /var/ITdemos/firstdemo-directory
        export EDITOR=$OLDEDITOR

    The second script contains the editing changes. In this example, the key-edit.sh script substitutes the word key for the word pey.

    #!/usr/bin/bash
        perl -pi.pfedit -e 's/pey/key/g' $1 
        rm $1.pfedit
    • The $1 finds the temporary file.

    • The perl -pi.extension creates a temporary file and writes back to the original file.

    • The rm command removes this extra temporary file.

  3. Call the first script.

    You can create more editing scripts, then replace the key-edit.sh script in the batchpfedit.sh with the new script name.