oddjob: Threat or Menace?

In many applications, particularly those which perform some sort of administrative task, it becomes useful to separate the presentation (which needn't have any special privileges, and frequently shouldn't) from the logic which actually performs the task (which frequently needs privileges).

In these situations, the unprivileged application typically accomplishes the privileged task either by running a setuid helper application or by connecting to a long-running process and issuing a request.

Of the two options, the setuid helper approach offers the advantage of requiring less configuration beforehand, but can be undesirable in the context of libraries or demand-loaded modules, when the direct caller may be unaware of the state of the calling application with regard to signal handling, which must be taken into account if the caller expects to wait for the privileged child process to complete its task. Additionally, certain attributes of the unprivileged process which are inherited by the privileged helper (current directory, other open file handles, environment variables) may be manipulated to become vectors for attack by malicious users.

The alternative, the use of a long-running process which services these requests, becomes attractive for these reasons. The primary objections to this approach are frequently:

A third option has recently become available: the D-Bus system message bus. The system message bus provides an interprocess communication mechanism to processes on the system. The bus carries three types of messages:

Method call and response messages which are sent over the system message bus provide a loosely coupled object-oriented RPC mechanism.

The D-Bus libraries also provide a means of encoding, transmitting, listening for, receiving, and parsing messages which are sent over the bus. Using D-Bus as the mechanism for a long-running process reduces the time required to implement both a long-running server and its clients. Because the implementation of the bus protocols is designed to be reused, it also offers the opportunity to have one privileged process service a potentially large number of clients.

The oddjob package implements such a server.

The server provided by oddjob, oddjobd, provides services which appear to be indistinguishable from other services provided through D-Bus, but in an unconventional manner. Before continuing, it is instructive to look at how clients and servers interact over the bus.

The fundamental unit of communication over the system bus is the message. For practical purposes, a message is composed of the addressing information which is needed to route that message to the proper recipient, and one of:

More specifically, each message includes the address of its sender. Method call and response messages should also include the address of the intended recipient. A bus address uniquely identifies a process which is connected to the message bus. Generally, a single process will have exactly one open connection to the message bus.

A message also includes an object path, which allows multiple client sessions to be serviced by the same server. Each object can provide multiple interfaces, which are groups of related methods.

The function of the oddjobd daemon is to allow arbitrary services to be provided over the message bus with a minimum of "glue". Services provided by oddjobd can be implemented very simply. This simplicity of implementation is gained at the cost of some robustness, but for certain applications this is an acceptable tradeoff.

An analogous comparison can be made between applications which are implemented on web servers using scripting engines and applications which are implemented using the Common Gateway Interface (CGI).

Take for example, a service which is provided by the well-known address "com.example.system_manager". This management service controls multiple systems, each of which is represented as a different object with a name of the form "/com/example/Systems/server1". Each object offers multiple interfaces, such as the "com.example.power" interface, which provides methods such as "reboot" and "poweroff".

Conventionally, the implementation of the "com.example.system_manager" service would require a long-running server process which would need to include logic for connecting to the system message bus, receiving requests, and issuing replies, in addition to its core functionality.

Using oddjobd, the entire implementation can be synthesized by providing the proper configuration files and shell scripts.

<!DOCTYPE busconfig PUBLIC
	  "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
	  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

<busconfig>

	<!-- Only root can own the system manager service. -->
	<policy user="root">
		<allow own="com.example.system_manager">
	</policy>

	<!-- Allow anyone to call the reboot and poweroff
	     methods.  This is probably a bad idea. -->
	<policy context="default">
		<allow send_destination="com.example.system_manager"
		       send_path="/com/example/Systems/server1"
		       send_interface="com.example.power"
		       send_member="reboot"/>
		<allow send_destination="com.example.system_manager"
		       send_path="/com/example/Systems/server1"
		       send_interface="com.example.power"
		       send_member="poweroff"/>
	</policy>

</busconfig>

<?xml version="1.0"?>
<oddjobconfig>
	<service name="com.example.system_manager">
		<object name="/com/example/Systems/server1">
			<interface name="com.example.power">
				<method name="reboot">
					<helper exec="/sbin/reboot"
						arguments="0"
						prepend_user_name="no"/>
					<!-- Only root and jimbo can use this -->
					<allow user="root"/>
					<allow user="jimbo"/>
				</method>
				<method name="poweroff">
					<helper exec="/sbin/poweroff"
						arguments="0"
						prepend_user_name="no"/>
					<!-- Only root and jimbo can use this -->
					<allow user="root"/>
					<allow user="jimbo"/>
				</method>
			</interface>
		</object>
	</service>
</oddjobconfig>

The oddjobd configuration is normally read from /etc/oddjobd.conf, but in most deployments it will direct the daemon to read all of the configuration files from /etc/oddjobd.conf.d, taking the union of the contents of all of the configuration files as its configuration.

Each configuration file includes an <oddjobconfig> element. An <oddjobconfig> element contains <include> elements, <service> elements, <allow> elements, and <deny> elements.

An <include> element names a file which should also be scanned for configuration data, and optionally defines an attribute named "ignore_missing", which if set to "yes" will cause failure to read the named file to be treated as a non-fatal error.

A <service> element names a D-Bus service address at which services defined within the scope of this element will be provided by oddjobd. The service address is given as the value of its "name" attribute, and it may contain <object> elements, <allow> elements, and <deny> elements.

An <object> element names a D-Bus object path which provides one or more interfaces to client processes. The object path is given as the value of its "name" attribute, and it may contain <interface> elements. Its name may include wildcards, in which case any request to an object whose name matches the wildcard will be considered to match this element.

The <object> element may also contain <allow> and <deny> elements.

An <interface> element names a group of related methods which oddjobd will provide at the containing <object>'s path. The interface name is given as the value of its "name" attribute. It may contain <method>, <allow>, and <deny> elements.

An <method> element names a specific method which oddjobd will provide as part of the containing <interface> at the containing <object>'s path. The method name is given as the value of its "name" attribute, and it may contain <helper>, <allow>, and <deny> elements.

An <helper> element specifies that a method is implemented as an external helper (oddjobd itself implements a limited number of methods internally). It includes a number of attributes:

An <allow> or <deny> element specifies an entry in an access control list (ACL) which controls whether or not oddjobd will attempt to fulfill client requests.

Each entry defines a set of values for attributes of a client request. If a specific request provides these values, the access control list entry is considered to match it. Attributes which are not specified as part of an access control entry are ignored when checking if a request matches that entry. The defined attributes are:

The process of checking the ACL for any method is simple:

The helpers themselves are executed with superuser privileges and with these variables set in the environment:

The current implementation of oddjobd imposes some limitations on clients.