Pegasus Enhancement Proposal (PEP)

PEP #:  286

PEP Type:  Functional

Title:  Privilege Separation

Status:  Approved

Version History:

Abstract: This PEP describes the inclusion of  privilege separation into the OpenPegasus server. Privilege separation aims to substantially reduce the amount of server code running with elevated privilege. This improves server security by limiting vulnerability to a family of client attacks, aimed at exploiting programming errors in order to perform unauthorized privileged operations. The best known example of this kind of attack is the buffer overrun attack [1]. The potential for this kind of attack can be limited by reducing the volume of code that executes with elevated privilege. 

A typical privilege separation implementation relocates all privileged code from a server into a separate executor process. Then the executor runs with elevated privilege whereas the server runs with reduced privilege. The executor carries out a limited set of privileged operations on behalf of the server. The executor defines a policy that restricts the allowable parameters to these privileged operations. Without a policy, programming errors in the server might be exploited to trick the executor into performing a privileged operation on an unauthorized object (e.g., the server might ask the executor to execute a rogue program). The executor, server, and policy are depicted in the diagram below.

	[executor] <--(requests)-- [server]
           ^
           |
        [policy]

Definition of the Problem

In the current Pegasus implementation, all Pegasus server code executes with elevated privilege, which makes the server vulnerable to security attacks aimed at exploiting programming errors in order to execute unauthorized privileged operations. The costs of identifying and fixing these flaws are prohibitive since all server source code must be audited.

Proposed Solution

	+-------------------+               +----------------------+                  +-------------------------+
	| policy definition |---- reads --->| executor (cimserver) |<---- socket -----| server (cimservermain) |
	+-------------------+               +----------------------+                  +-------------------------+
          owner=root                         user=root                                 user=non-root

Note that while the diagram above shows the policy definition in a file, in this implementation it will be statically compiled into the executor program.

Executor Process

1. Initialize the static policy definition in memory.
2. Create a Unix domain socket pair (used to communicate with the server).
3. Fork server process (tying standard output/error together).
• Set process user id to ordinary user (configuration option).
• Set process group id to ordinary user (configuration option).
• Locate cimservermain program (configuration option).
• Exec cimservermain program with the same command line options given to cimserver.
4. Read client request from socket.
• If end of file encountered on socket, then exit (cimservermain has stopped).
• If valid request is received:
  • Check request against embedded policy.
  • If permitted by policy, perform the request and return the result on the socket.
  • Else, log and reject request, and possibly shutdown the server (cimserver and cimservermain).
• Repeat step 4.

Executor Operations

The executor supports the following operations:

Details about the input and output parameters for each of these operations can be found in the pegasus/src/Executor/Messages.h file

The executor will be written from scratch, since using any of the existing Pegasus libraries would unnecessarily widen the scope of source-level security audits. In other words, the executor implementation will be self contained and will not include any existing Pegasus headers nor will it link any existing Pegasus libraries. Further, the entire executor implementation will be contained in a single source code directory.

Executor Policy Definitions

Policies will define restrictions on the parameters of the supported operations.  In general a policy consists of the operation name followed by parameter restrictions.  For example, these entries allow the Pegasus configuration files to be opened for writing:

	OpenFile("/pegasus_home/cimserver_current.conf", "w")
	OpenFile("/pegasus_home/cimserver_planned.conf", "w")

Similarly, this policy allows any file in the /tmp directory to be removed:

	RemoveFile("/tmp/*")

If a policy statement cannot be located for a given request, then the request is rejected.

Policy definitions are statically compiled into the executor and cannot be configured at runtime.

Executor Logging

1. Authentication failures.
2. Authorization failures.  The only type of authorization failure that can occur in the executor is the failure to exec cimprovagt as a given user (if the user has insufficient privilege to run it). This failure will be logged as "user X failed to exec Y".
3. Policy breaches (e.g., an attempt to exec an unknown program or to open an unknown file).

Server Process

1. Obtain the socket inherited from the executor (needed to communicate with the executor).
2. Tell the executor to daemonize (if and when the server daemonizes).
3. Send requests to the server over the socket using the Executor class interface.
4. Cache client credentials long enough so that they may be passed to the run-provider-agent command (for "run as requestor" mode).

If privilege separation is not enabled, the server will operate without using the calls to the Executor to perform root privilege functions.  The external behavior is unchanged in this case.

The Server's Executor Class

File Ownership and Access

The following table defines file ownership and server user access privileges.  The executor may override the access privileges (based on policy definitions) by opening the file on behalf of the server and passing back a descriptor.

Affected Source Files

In the CIM Server itself, the following source files will contain the bulk of the changes. Minor changes are expected in a few others.

• cimserver.cpp - Set up the executor socket and request executor to daemonize itself.
• PAMBasicAuthenticatorUnix.cpp - Use the executor to perform the part of authentication requiring privileges.
• SecureBasicAuthenticator.cpp - Use the executor to perform the part of authentication requiring privileges.
• SecureLocalAuthenticator.cpp - Use the executor to perform the part of local authentication requiring privileges.
• OOPProviderManagerRouter.cpp - Use the executor to fork and exec the cimprovagt process.
• ServerProcessUnix.cpp - Avoid the cimservermain daemonization logic.
• CertificateProvider.cpp - Use the executor to access trust store and CRL store files.
• SSLContext.cpp - Use the executor to open the SSL private key file.
• Config/ConfigFileHandler and ConfigFile - Use the executor for config file write operations since these files are maintained as root.
• Security/UserManager - Use the executor to access the local password file.
• cimservera - This is the existing PAM out-of-process support code rewritten to reduce security audit scope (now has no dependencies on other Pegasus libraries).

New Runtime Files

• cimshutdown - a standalone program to shut down the cimserver.  It is an internal program invoked by "cimserver -s".
• cimservermain - most of the program formerly called cimserver.  (The executor program is now named "cimserver".)

Supported Platforms

• HP-UX
• Linux

Build Environment Variables

These environment variable definitions will be proposed for PEP 292 (Recommended OpenPegasus 2.7.0 Build and Configuration Options for Selected Platforms):

PEGASUS_ENABLE_PRIVILEGE_SEPARATION

Description: Builds a version of OpenPegasus that enables the Privilege Separation feature.  This feature allows the CIM Server to run in a non-privileged user context and use a small executor process to perform privileged operations.
Default Value: Not Set
Recommended Value (Development Build): true (HP-UX, Linux)
Recommended Value (Release Build): true (HP-UX, Linux)
Required: No
Considerations: The Privilege Separation feature is only supported on HP-UX and Linux platforms.  The "cimsrvr" user must be defined on the system.  If the umask setting in the environment is not 0, PEGASUS_TMP must be set to a directory that is writable by the "cimsrvr" user for the tests to run successfully.

Building with Privilege Separation

• Set the PEGASUS_ENABLE_PRIVILEGE_SEPARATION environment variable to "true".
• Create the "cimsrvr" user on the system.
• If the umask is not set to 0 in the environment, set the PEGASUS_TMP environment variable to a directory writeable by the server user to allow the tests to run successfully.

The behavior of Pegasus is unchanged when privilege separation is not built. That is:

1. No executor program is built.
2. The cimserver program is built as before and there is no cimservermain program.
3. All privileged operations are performed by the Executor class in the cimserver, rather than by the executor process.

Design Considerations

These questions were considered during the design process.  The resolutions are given after each question.

1. What is the best way for the executor to obtain the user-id and group-id that the server will run as?  The user context for the non-privileged component of the server is defined as "cimsrvr" in the build system (in config.mak).
2. How will the executor program (cimserver) locate the server program (cimservermain)? The executor uses the constant for cimprovagt in Constants.h and then removes "cimprovagt" and appends "cimservermain".
3. Should the server (executor and server) stop if an attack is in progress (standard practice)? And if so, how do we keep third-party watchdog processes from restarting it? No but it is logged and is easy to configure.
4. How will legacy in-process providers that formerly required root privilege continue to work? They must be modified to use the executor or moved out-of-process. We cannot depend on providers being modified to use the executor. Most of  providers should work out-of-process automatically. The exceptions are cases where the provider was relying on a no-no, such as sharing objects in memory with another provider. In these cases, the provider must be updated to work out-of-process to work with a server using privilege separation.
5. Does this proposal introduce a potential for collisions between a running cimserver/cimservermain and the starting of another cimserver? The current cimserver(main) program protects against these collisions, but if the executor does anything interesting before starting cimservermain, there could be a problem.  There is a function called TestCimServerProcess() in the Executor that checks to see if cimservermain is already running to avoid collisions.

Requirements

1. The executor must implement all privileged operations performed by the Pegasus server today (see table above).
2. The apparent external behavior of the Pegasus server must not change.
3. No Pegasus public interfaces may be change (programming interfaces and command-line interfaces).
4. Providers may run out-of-process as any user (including root) as was the case before this change.
5. Without privilege separation enabled, the Pegasus server must behave as before (including the ability to run as an ordinary user).
6. The executor process must log security diagnostics and alerts to syslog (configurable).
7. The server user must be configurable in the build environment.
8. The executor program must not include any Pegasus headers or link to any Pegasus libraries.
9. The executor program must have fewer than 5000 lines of code.
10. The executor must shutdown properly when the Pegasus server shuts down.
11. The Pegasus server must pass all the end-to-end tests when configured to use executor.
12. Pegasus shall continue to compile and work on all platforms (although only HP-UX and Linux will initially support privilege separation mode).
13. Flawfinder will be run against the executor regularly to identify and fix potential problems.
14. The executor will avoid the use of strcpy(), strncpy(), strcat(), and strncat(), and use strlcpy() and strlcat() in their place.
15. The following authentication will be moved into the executor:
    1. Local Authentication
    2. PAM in process authentication
    3. PAM out-of-process authentication.
    4. Password file authentication.

Non-requirements

1. Privilege separation is not required on Windows (although Windows will continue to work without privilege separation as before).
2. Out-of-process providers are not required to perform privileged operations via the executor (as before, an out-of-process provider can be registered to run as root at the discretion of the provider writer).
3. In-process providers will not be restricted from performing privileged operations via the executor. Security is best obtained using out-of-process providers in conjunction with the executor.
4. Providers with Privileged UserContext are not required to run in-process.  Providers with Requestor and Designated UserContext will remain out-of-process.
5. In-process providers will still be able to interfere with the correct operation of the executor and server.
6. While all authentication should be in a separate process/trust-domain (to reduce risk) than the cimserver (unprivileged where possible), this PEP doesn't move all of them due to time/resource constraints.  Specifically the following authentication will not be moved into the executor:
   1. SSL Client Certificate authentication (Others are encouraged to contribute moving certificate authentication to a separate (security-reviewed, small) process)
   2. Kerberos authentication (since the developers do not have access to a Kerberos implementation)

Testing

Deferred Items

Session Authorization

1. Each operation connection will be allocated a session key by the executor as part of authentication. This session key will be carried as part of all operations that are received by the server during the client connection. This key can be used by the executor to validate that the user identification for each operation is the same identification as the original authentication. Specifically, it will be tested as part of the executor function of starting a provider agent.
2. Dynamic policies will be used to constrain which providers may be started in which user contexts.
3. The executor must implement these additional functions and operations to manage session keys:

Dynamic Policies

Static policies are compiled into the executor and cannot change.  Dynamic policies can be specified at runtime.  Dynamic policies are stored in a file (cimserver_policy.conf) owned by root and writable only by root.  The policies used by startProviderAgent to define provider access are the only policies that are dynamic.  These dynamic policies are intended to encapsulate the provider user context definitions in the provider registration, so that the CIM Server cannot request a provider to be started in a user context that is not intended.

It may seem that provider user context configuration could be retrieved directly from the provider registration information in the repository instead of maintaining a separate but parallel policy file.  However, the executor cannot trust the repository since it can be written by the server user.  Also, it is technically infeasible for the executor to access the repository because that program is prohibited from linking with Pegasus libraries (for code auditing purposes).

Therefore, a mechanism is needed to keep the dynamic policy definition consistent with the provider registration information.  Some options are:

• The information can be synchronized manually by an administrator.  (This approach is tedious and complex for an administrator and is error prone.)
• A standalone command line tool can be used to generate the policy definitions from the provider registration information.  (When to invoke this tool and how to know whether to trust the repository are open questions.  Administrator intervention is required.)
• Extend the MOF compiler to automatically update the dynamic policy file when a PG_ProviderModule instance is compiled.  To ensure that only intended MOF files are compiled, the directories in which these MOF definitions may exist can be limited by a list of authorized directories.  A fixed list can be compiled into cimmof and a PEGASUS_TRUSTED_DIRS environment variable can be used to extend the list.  (This approach does not support MOF that is sent to cimmof via stdin and does not support provider registration though CIM operations outside the MOF compiler.  It also assumes a complete list of directories containing "valid" MOF files can be known at compile time, or else it requires administrator intervention.  Since "valid" MOF files are delivered with provider installations, the locations may be difficult to predict.  The removal of policies when a provider is unregistered is also not addressed.)

1. Before cimmof creates a PG_ProviderModule instance, it checks to see if the MOF file resides in or below a "trusted directory". If not, the registration attempt is rejected. The list of trusted directories is defined by two sources:
   • A static compile-time array of trusted directories (see pegasus/src/Pegasus/Compiler/Policy.cpp). This array includes /usr, /opt/ and /etc. Vendors may wish to modify this list for their platforms.
   • The PEGASUS_TRUSTED_DIRS environment variable (defined by the user who runs cimmof). The format of the value is identical to the format used in the PATH environment variable (i.e., a colon-separated list of directories).
2. After cimmof creates a PG_ProviderModule instance (via the client), it adds a corresponding line to the cimserver_policy.conf file.  cimmof must run as root in order to write to the cimserver_policy.conf file (which is already required by the CIM Server when registering a provider module).

References

Copyright (c) 2006 Hewlett-Packard Development Company, L.P.; IBM Corp.;
EMC Corporation; Symantec Corporation; The Open Group.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN
ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED
"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.