type=AVC msg=audit(1164222416.269:22): avc:  denied  { use } for  pid=1940 comm="setsebool" name="0" dev=devpts ino=2 \
	scontext=system_u:system_r:semanage_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=fd

The audit2allow utility now has the ability to build policy modules. Use the following command to build a policy module based on specific contents of the audit.log file:

[root@host2a ~]#  grep setsebool /var/log/audit/audit.log  | audit2allow -M mysemanage
Generating type enforcement file: mysemanage.te
Compiling policy
checkmodule -M -m -o mysemanage.mod mysemanage.te
semodule_package -o mysemanage.pp -m mysemanage.mod

******************** IMPORTANT ***********************

In order to load this newly created policy package into the kernel,
you are required to execute

semodule -i mysemanage.pp

The audit2allow utility has built a type enforcement file (mysemanage.te). It then executed the checkmodule command to compile a module file (mysemanage.mod). Lastly, it uses the semodule_package command to create a policy package (mysemanage.pp). The semodule_package command combines different policy files (usually just the module and potentially a file context file) into a policy package.

Use the cat command to inspect the contents of the TE file:

[root@host2a ~]# cat mysemanag.te
module mysemanage 1.0;

require {
	class fd use;
	type init_t;
	type semanage_t;
	role system_r;
};

allow semanage_t init_t:fd use;

The TE file is comprised of three sections. The first section is the module command, which identifies the module name and version. The module name must be unique. If you create an semanage module using the name of a pre-existing module, the system would try to replace the existing module package with the newly-created version. The last part of the module line is the version. semodule can update module packages and checks the update version against the currently installed version.

The next block of the TE file is the require block. This informs the policy loader which types, classes and roles are required in the system policy before this module can be installed. If any of these fields are undefined, the semodule command will fail.

Lastly are the allow rules. In this example, you could modify this line to dontaudit, because semodule does not need to access the file descriptor.

The last step in the process of creating a local policy module is to load the policy package into the kernel.

Use the semodule command to load the policy package:

[root@host2a ~]# semodule -i mysemanage.pp

This command recompiles the policy file and regenerates the file context file. The changes are permanent and will survive a reboot. You can also copy the policy package file (mysemanage.pp) to other machines and install it using semodule.

The audit2allow command outputs the commands it executed to create the policy package so that you can edit the TE file. This means you can add new rules as required or change the allow rule to dontaudit. You could then recompile and repackage the policy package to be installed again.

There is no limit to the number of policy packages, so you could create one for each local modification you want to make. Alternatively, you could continue to edit a single package, but you need to ensure that the "require" statements match all of the allow rules.