State and event files

State files

When you run secpolgenerate with the -s option and the path to a file on a writable file system, whenever secpolgenerate receives a SIGTERM, before it exits, it saves in the specified file all the data related to abilities that processes associated with a type used or failed to use. The next time you run secpolgenerate, it restores its previous state by reading the file.

Normally, secpolgenerate uses numeric IDs for types and abilities when it saves its state, which is the most efficient format. To configure secpolgenerate to use names for types and abilities instead, which makes the information easier to interpret, specify -n.

Event files

You can also manually load files that use the same format as a state file into secpolgenerate to simulate the use of abilities. These event files can be useful, for example, when you know that a process with a specific security type only sometimes uses one or more privileges. Injecting the events via an event file makes sure that any generated policy includes the privileges, even if the type doesn't need them when the policy is generated.

Another use case is when privileges that are needed appear in the secpolgenerate unused file because they are only required in rare situations. Instead of allowing these privileges to continue to appear in the unused file, you can create one or more event files to simulate the privileges being used. (It is helpful to document the circumstances under which you expect them to be used.) This technique can help reduce the unused file to just those privileges that you should consider removing from the policy.

To generate an event file, you create a file that describes the appropriate types and rules using the security policy language and compile it using secpolcompile with -e. Then, use the following command to inject it into the secpolgenerate process:

secpolgenerate -C load event_file

Event file example

This example makes sure that the process of type devb_t has the path_trust ability. This configuration might be useful if, for example, you only sometimes mount filesystems as trusted.

First, create the file devb_pt.txt, which defines the type and rule using the security policy language:

type devb_t;

# Allow devb process to provide trusted file systems
allow devb_t self:ability {
    nonroot
    path_trust
};

Then, compile the file using secpolcompile with -e:

secpolcompile -e -o devb_pt.event devb_pt.txt

When you run secpolgenerate, include the file using the -C load option:

secpolgenerate -C load devb_pt.event

In the generated policy, it will now appear as if a process of type devb_t makes use of the path_trust ability.