next up previous contents
Next: RBAC configuration Up: Policy Configuration Language Previous: Policy Configuration Language   Contents

TE configuration

The all.te file contains the configuration information for the type enforcement (TE) policy. This file is automatically generated from a collection of files. The macros.te file contains global macros used throughout the configuration for common groupings of classes and permissions and for common sets of rules. The assert.te file contains assertions that are checked after evaluating the entire TE configuration.

The types subdirectory contains several files with declarations for general types (types not associated with a particular domain) and some rules defining relationships among those types. Related types are grouped together into each file in this directory, e.g. all device type declarations are in the device.te file.

The domains subdirectory contains several subdirectories with a separate file containing the declarations and rules for each domain. Related domains are grouped together into each subdirectory, e.g. all domain definitions for system processes are in the domains/system subdirectory. The domains/every.te file contains rules that apply to every domain.

In a traditional TE policy, each subject is labeled with a domain, and each object is labeled with a type. A domain definition table (DDT) specifies the permissions granted between domains and types, and a domain interaction table (DIT) specifies the permissions granted between domain pairs. In contrast, the security server prototype merges the concept of domains and types into a single type abstraction, and maintains a single table that specifies the permissions granted between pairs of types. To the security server, a domain is simply a type that can be associated with a process. The TE configuration contains seven kinds of statements: type declarations, type transition rules, type member rules, type change rules, access vector rules, cloning rules, and access vector assertions.

A type declaration specifies a primary name for a type, an optional set of alias names, and an optional set of attributes. The primary name is always returned as the type by the security_sid_to_context call. The primary name or any of the alias names may be used for the type in a security_context_to_sid call. An attribute may be used to identify a set of types with similar properties. When an attribute name is used in a rule, it is expanded to the set of types with that attribute. Primary names, alias names, and attribute names all exist in the same name space.

Although domains are not distinguished from types by the security server, they can be optionally distinguished in the policy configuration using a ``domain'' attribute. A ``domain'' attribute has no intrinsic meaning to the security server, and is only meaningful to the extent the policy configuration uses the attribute in rules.

Figure: Type declarations.
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}type syslogd...
...ype devlog_t, file_type;\end{verbatim}\end{footnotesize}\end{center}\end{figure}

Sample type declarations for the syslogd daemon are shown in Figure 1. The syslogd_t type is the domain of the daemon process, so a domain attribute is associated with it. The syslogd_exec_t type is the type of the daemon program executable, so it is associated with both a file_type attribute and a exec_type attribute. The devlog_t type is the type of the /dev/log socket file created by the daemon for receiving local log messages, so it is associated with a file_type attribute. These attributes have no intrinsic meaning to the security server, but they can be used in rules in the configuration.

A type transition rule specifies the default type of a transformed process or the default type of a new file based on the type of the creating subject and the type of a related object. For a process, the related object is the program executable. For a file, the related object is the parent directory. If no rule is specified, then the default type of a transformed process is the same as its type prior to the execve call, and the default type of a new file is the same as the type of its parent directory. The default type is returned by the security_transition_sid call.

Each type transition rule has a creating subject type field, a related object type field, a class field, and a default type field. To permit concise specification of multiple type transitions, the type fields other than the default type field may contain a set of types, and the class field may contain a set of classes. An attribute name may be used to indicate the set of types with that attribute. A tilde may precede a set of types to indicate the complement of the set. An asterisk may be used to indicate all types. If multiple type transition rules are specified for a given type pair and class, then warnings are issued by the policy compiler and the last such rule is used.

Figure: Type transition rules.
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}type_transit...
..._t:sock_file
devlog_t;\end{verbatim}\end{footnotesize}\end{center}\end{figure}

Sample type transition rules for the syslogd daemon are shown in Figure 2. The first transition rule specifies that when an rc script executes the syslogd program executable, the transformed process should be assigned the syslogd_t type by default. The second transition rule specifies that when syslogd creates a socket file in /dev, the socket file should be assigned the devlog_t type by default. The device_t type is the type assigned to the /dev directory, and the sock_file class is the security class for socket files.

A type member rule specifies the type of the member object in a polyinstantiated object that should be accessed by default based on the type of the accessing process and the type of the polyinstantiated object. If no rule is specified, then the type of the polyinstantiated object is used for the member. A type member rule has the same syntax as a type transition rule except that it uses the type_member keyword.

A type change rule specifies the type to use for relabeling an object based on the type of the process and the current type of the object. If no rule is specified, then the type of the object is unchanged. A type change rule has the same syntax as a type transition rule except that it uses the type_change keyword.

An access vector rule specifies the permissions in an access vector based on a source type, a target type, and a class. There are four kinds of access vector rules: allow, auditallow, auditdeny, and notify. These rules define the corresponding access vectors returned by security_compute_av. If no rule is specified, then no permissions are returned in allowed, auditallow, or notify, and all permissions are returned in auditdeny. All permissions are always returned in the decided access vector, since the TE policy does not defer the computation of any permissions.

Each access vector rule has a source type field, a target type field, a class field, and a permissions field. As with type transition rules, sets of types and classes may be specified in the corresponding fields, and the asterisk and tilde characters may be used. Asterisk and tilde may also be used in the permission field. The name self may be used in the target type field to indicate that the rule should be applied between each source type and itself. If multiple access vector rules are specified for a given type pair and class, then the union of the permission fields is used.

Figure: Access vector rules
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}allow
doma...
...og_t:sock_file
create;\end{verbatim}\end{footnotesize}\end{center}\end{figure}

Sample allow access vector rules are shown in Figure 3. The first rule grants every domain the ability to send a SIGCHLD signal to init, so that init can reap every process. The second rule grants syslogd the ability to access /dev to replace /dev/log. The third rule grants syslogd the ability to create the /dev/log socket file.

A cloning rule specifies that the type transition and access vector rules defined for a specified source domain should be cloned for a specified target domain. A type transition rule for a process is not cloned if the default type in the rule is equal to the source or target domain in the clone statement. Hence, transitions from the source domain to itself or to the target domain are not cloned for the target domain. An access vector rule is not cloned if the target type in the rule is equal to the source or target domain in the clone statement. Hence, permissions between the source domain and itself or between the source domain and the target domain are not cloned for the target domain.

An access vector assertion specifies permissions that should not be in an access vector based on a source type, a target type, and a class. If any of the specified permissions are in the corresponding access vector, then the policy compiler will reject the policy configuration. Currently, there is only one kind of access vector assertion, neverallow, but support for the other kinds of vectors could be easily added. Access vector assertions use the same syntax as access vector rules.

Figure: Domain cloning and access vector assertions.
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}clone
user...
...b_t }:process
execute;\end{verbatim}\end{footnotesize}\end{center}\end{figure}

A sample domain cloning rule and a sample access vector assertion are shown in Figure 4. The cloning rule clones the type transition rules and the access vector rules of the user_t domain for the sysadm_t domain. The access vector assertion rule verifies that the syslogd daemon process may only execute code from its program executable, the dynamic loader, and the system shared libraries.


next up previous contents
Next: RBAC configuration Up: Policy Configuration Language Previous: Policy Configuration Language   Contents