Kevin Van Horn
Dan Nuffer
Note: a “passive” provider is an instance provider, secondary
instance provider, method provider, or associator provider.
Separate processes act as bulkheads to limit the damage that may be caused by bugs and exploits.
Privileges of a subsystem limited based on userid of its process.
Wherever practical, code runs only with the userid of the entity that initiated the operation.
Only a small amount of code, in 2 subsystems — the monitor and the connection handler — runs as root.
Below are the various processes that comprise the CIMOM. Those that persist for the entire time the CIMOM is running are marked with P (persistent); those that last for only the duration of a single CIMOM request (or less) are marked with T (transient); others of intermediate duration are marked with S (semipermanent).
The Monitor may grant other subsystems (OpenWBEM processes) limited capabilities that they would not otherwise have.
Monitor knows identity of a subsystem process because it created the process and created a Unix domain socket pair for communicating with it.
The sendmsg / recvmsg systems calls used to pass descriptors from monitor to subsystem process.
Kinds of requests a subsystem process might make to monitor:
Monitor has its own access control lists that specify what requests a particular subsystem process can make (includes allowable arguments). This may also take into account the sequence of requests the subsystem has made, using a FSM.
If subsystem makes a disallowed request, the monitor will no longer
accept
requests from the subsystem. (Should it go so far as to kill the
process?)
All startup/shutdown/restart activity is coordinated by the monitor
Runs as the OpenWBEM-Logger user. All logging is done by sending a message to the logger. All processes created by the monitor are given a descriptor for sending messages to the logger. After creating a log file, but before writing to it, the logger asks the monitor to change its owner to root so that only root can read the log output.
Runs as the OpenWBEM-Repository user. All repository files are owned by this user, and accessible only by owner. The repository holds access control lists that control what operations are alowed based on userid, groupid?, namespace, and class. When the monitor grants a process access to the repository server, it associates the userid of the requester with the descriptor it passes to the repository server. The access control lists are implemented as CIM instances in the repository. The repository also contains information identifying which providers are associated with a class.
This process exists only on platforms that lack an acceptable /dev/urandom or its equivalent. It runs a cryptographically strong pseudo-random number generator, seeded by the output of an entropy collector. (Do we restrict access to this server in some way to prevent DOS attacks?)
The Connection Handler Creator accepts connections to the CIMOM, and for each connection it forks off a connection handler process. (The purpose of the CHC is to reduce startup times, as it has already done the initialization the CH process will need.) The CH and CHC processes run as root. A CH process is responsible for parsing HTTP headers sufficiently to carry out authentication, as well as doing SSL client authentication (the reason it isn't a security advantage to run as a non-privileged user). Once authentication has occurred it changes to the appropriate userid. Then, the request is parsed and the operations requested of the CIMOM are performed, doing as much of the work itself as is practical. It runs as the user making the request, as determined in the authentication phase. It accesses the repository server for operations on static data and to find out what providers (if any) it must use to carry out the operation.
The CH loads and runs any needed passive providers; hence these providers can only do whatever the requesting user is authorized to do. These providers may in turn request certain capabilities (typically file descriptors opened for reading) from the monitor; these capabilities will be granted or not depending on the userid of the process.
Some passive providers may run as independent processes because they are implemented in a scripting language (e.g., Perl) or to be isolated from C++ binary compatibility problems. These run with the same userid as the CH, and again request from the Monitor any special capabilities they may need.
Described above under “Connection Handlers”
Runs as the OpenWBEM-indication-server user. Handles activation and deactivation of indication providers and runs indication export providers and subscription filters (the “where” clause).
When a CH process requests creation of an indication subscription, the indication server first contacts the repository server to determine if that user has permission to receive indications of the requested indication class, processed by the (provider for the) requested indication handler class. If so, it sends the appropriate activate message to the appropriate indication provider process, asking the monitor to create the process if it doesn't already exist, and updates its internal data structures for handling indications.
When asked to remove a subscription, the indication server checks to see if the requester's userid is either explicitly authorized to remove the subscription (based on indication class and indication handler class) or is the same userid used to create the subscription. If so, it sends the appropriate deactivate message to the indication provider, and updates its internal data structures for handling indications.
The indication server receives all indications generated by indication providers and runs the appropriate indication export providers to process them.
There is one of these for each active indication provider. An IPP runs the code for an indication provider, sending the generated indications to the indication server. It may request certain capabilities (typically file descriptors opened for reading) from the Monitor; these capabilities will be granted or not depending on which indication provider is requesting them.