Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## 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 the manual Developer’s Guide to Oracle Solaris 11 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

- Using the `application_user` Property

- Using the `scha_check_app_user` Command

### 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`(1M) 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`(1HA) man page for more information.

Copyright © 2000, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |