Go to main content

Developing Data Services

Exit Print View

Updated: August 2018
 
 

Invoking Application Programs with Least Privilege

A data service can invoke an application following the concept of least privilege to decrease the possibility of a security breach. With this approach, you require the application to be executed with the minimal privileges required to perform its tasks.

See Developer’s Guide to Oracle Solaris 11.4 Security in the Oracle Solaris 11 documentation library for more information about developing privileged applications in Oracle Solaris 11.

As good security practice, application programs should not be run as root. Executables generally should be owned by root and run as non-root. If an executable binary or script owned by a non-root user can be executed as root, it would be possible for the non-root user to insert malicious operations into that executable, which could be executed with full privileges.

Cluster agent methods should run all external programs using a wrapper to ensure that the external program is executed with the correct username and privilege.

Oracle Solaris Cluster provides the application_user and resource_security properties and the scha_check_app_user command to enable data services to ensure that the application is executed securely. The scha_check_app_user command can be called in scripts to verify the username against the configured application_user and resource_security settings.

See the following sections for information about using resource properties and commands to set up a data service to run with the least privileges required.

Using the resource_security Property

In the current Oracle Solaris Cluster release, the execution of a cluster resource is controlled by the setting of a global cluster property called resource_security, which is set to SECURE by default. This setting ensures that the execution of resource methods is secure.

Resource methods such as Start and Validate always run as root. If the method executable file is owned by a username other than root or allows write permission for the UNIX group or world, an insecurity exists. In this case, if the resource_security property is set to SECURE, execution of the resource method fails at run time and an error is returned. If resource_security has any other setting, the resource method is allowed to execute with a warning message. Permissible values of resource_security are SECURE, WARN, OVERRIDE, or COMPATIBILITY.

A cluster administrator can set the resource_security property for a cluster by using the cluster command, and for a zone cluster by using the clzonecluster command. The clsetup utility can also be used.

If a cluster is upgraded from an earlier release which does not include this property, the resource_security property is set to COMPATIBILITY to ensure that executables can run. However, the administrator should change the setting to SECURE.

For example, the following command sets the property to SECURE on a cluster:

# cluster set -p resource_security=SECURE

The resource_security setting also modifies the behavior of resource types that declare the application_user resource property, as described in the following section.

Using the application_user Property

A data service can declare the application_user resource property to provide a way for the cluster administrator to specify a non-root Solaris user name to be used for execution of application programs by the data service.

If your agent declares the application_user property, it is expected to set the user ID for execution of application programs according to the settings of the application_user resource property and the resource_security cluster property. You can use the scha_check_app_user command to help with this task. See Using the scha_check_app_user Command for more information.

If resource_security is set to COMPATIBILITY, the setting of the application_user resource property is ignored and the application user will be the user ID of the caller (usually root). This behavior is compatible with previous releases of Oracle Solaris Cluster.

If resource_security is set to OVERRIDE, the application_user property is ignored and the application user will be the owner of the application program executable file.

If resource_security is set to SECURE or WARN, the application user will be the value of the application_user resource property; however, if application_user is unset or empty, the application user will be the owner of the application program executable file.

Using the scha_check_app_user Command

You can use the scha_check_app_user command to obtain the configured application user name for a resource that is under the control of the RGM, and check the ownership and permissions on an executable file. The executable file is typically an application program that is intended to be executed by a method or monitor of the resource, using a wrapper such as su(8) to set the user ID to the configured user. The resource method or monitor should invoke scha_check_app_user prior to execution of the application program. Depending on the output of scha_check_app_user, the method or monitor should return an error or output a warning message if security-related problems are detected.

See the scha_check_app_user(8HA) man page for more information.

Executing the Application Under a Specified Oracle Solaris Project

If the su username command is used in a Prenet_start or Start method to execute the application program as a specified user, the application runs under the Oracle Solaris project associated with the username, regardless of the setting of the Resource_project_name resource property or RG_project_name resource group property.

To restore the correct behavior of the Resource_project_name and RG_project_name properties, execute newtask(1) to set the project name after executing the su command. The user-specified project name can be determined by querying the Resource_project_name resource property and the RG_project_name resource group property. If Resource_project_name is set to a non-empty value, its value takes precedence and must be used in the newtask command. If Resource_project_name is null or empty, the value of RG_project_name (if non-empty), must be used. If both of these properties are null or empty, your Start method can set a particular project name, for example default, or can allow the application to execute under the project associated with the username.