LINUXOR.SK ... open source notes ...

Email - postfix-local.te (SELinux module)

category: solutionz · date: 2019-12-31 · updated: 2026-10-02 · author: LALA

Email Solution · Config document · referenced from Virtual machines and OS build

A local SELinux type-enforcement module for Postfix with the encryption filter. The filter runs as a child of Postfix pipe, in the domain postfix_pipe_t, and the stock policy does not let that domain start GnuPG, keep working files and a log under the Postfix spool, or have that log rotated.

ItemValue
Path on the server/etc/selinux/postfix-local.te
Shown hereDC2-A-VCMSX001
Also onDC2-B-VCMSX001 and DC2-A-VCMSX002, identical
Compiled withcheckmodule -M -m -o postfix-local.mod postfix-local.te, then semodule_package -o postfix-local.pp -m postfix-local.mod
Loaded withsemodule -i postfix-local.pp
SELinux modeenforcing, targeted policy

The file

c
module postfix-local 1.0;

require {
        type var_t;
        type var_log_t;
        type system_mail_t;
        type postfix_spool_t;
        type postfix_pipe_t;
        type logrotate_t;
        type user_home_dir_t;
        type gpg_exec_t;
        type gpg_agent_exec_t;
        class dir { create read add_name remove_name write rmdir };
        class file { create execute execute_no_trans getattr link lock open read rename setattr unlink write append };
}

# The filter script, started by pipe(8): run gpg and gpg-agent, create and
# remove working and archive directories and files under the Postfix spool,
# write its own log (labelled var_log_t, see below), touch the home directory
# of the filter account where GnuPG keeps its keyring.
#============= postfix_pipe_t ==============
allow postfix_pipe_t gpg_agent_exec_t:file { execute read };
allow postfix_pipe_t gpg_exec_t:file { execute execute_no_trans open read };
allow postfix_pipe_t postfix_spool_t:dir { create add_name remove_name write rmdir };
allow postfix_pipe_t postfix_spool_t:file { create open write read getattr unlink };
allow postfix_pipe_t var_t:dir { add_name remove_name write };
allow postfix_pipe_t var_log_t:file { create getattr link lock open read rename setattr unlink write append };
allow postfix_pipe_t user_home_dir_t:dir write;

# The sendmail command, called by the filter to put the message back into
# Postfix, reads the message file from the spool.
#============= system_mail_t ==============
allow system_mail_t postfix_spool_t:file { getattr read };

# logrotate rotates the filter log, which lives under the Postfix spool.
#============= logrotate_t ==============
allow logrotate_t postfix_spool_t:dir read;
allow logrotate_t postfix_spool_t:file { create getattr link lock open read rename setattr unlink write };

The comment lines above each block are mine; the rules are as built.

What goes with it

The log directory of the filter was given the label of /var/log before the module was loaded, which is why the module speaks of var_log_t. The commands ran as root on both nodes of the internal pair.

bash
$ semanage fcontext -a -e /var/log /var/spool/postfix/bash-postfix-encrypt-filter/log
$ restorecon -R -v /var/spool/postfix/bash-postfix-encrypt-filter/log/

Differences between versions

WhereWhat is different
First concept, design document of 2018No var_log_t, logrotate_t or user_home_dir_t; instead allow postfix_pipe_t var_t:file { create getattr link lock open read rename setattr unlink write };, under a warning from audit2allow that var_t is a base type
As archived in 2019The file above: the log directory is labelled var_log_t, the var_t:file rule is gone, logrotate is allowed in
DC2-A-VCMSX002The same module is loaded, although the filter does not run there

Checked against RHEL 10.2

As builtToday
.te compiled with checkmodule -M -m, packaged with semodule_package, loaded with semodule -iStill works; checkpolicy and policycoreutils are shipped. The Red Hat SELinux guide for RHEL 10 no longer shows checkmodule: it shows audit2allow -M <name> followed by semodule -X 300 -i <name>.pp, and local modules written as .cil files that semodule -i loads directly
A local module with its own rulesRed Hat states that custom modules with own rules are outside the support scope

The type names used in the module (postfix_pipe_t, gpg_exec_t, gpg_agent_exec_t and the others) were not checked against the current policy, so I cannot say whether the file would compile unchanged.

← solutionz