SELinux preventing /etc/aliases email pipe to script from working

emailpermissionspipepostfixselinux

When somebody sends an email to my server, e.g.

somestringthatisnotnecessarilyauser@myserver.com

I want it to pipe to a PHP script. So in my

/etc/aliases

file I have:

somestringthatisnotnecessarilyauser: "|/path/to/php/script.php"

With SELinux disabled, it sends the email to the PHP script perfectly.

With SElinux enabled, the maillog is coming out with a permissions error:

local[19660]: fatal: execvp /path/to/php/script.php: Permission denied

I am quite new to SELinux but I have pinned the problem down to SELinux, because with it disabled, it works fine.

Does anybody know what semanage commands, or other policy, I need to apply to get this working with SELinux enabled?

OS is Centos6.5 64 bit

Here is what the /var/log/audit/audit.log is saying when sending email to address:

type=AVC msg=audit(1395174916.444:476603): avc:  denied  { search } for  pid=25396 comm="local" name="web" dev=dm-0 ino=522246 scontext=unconfined_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir
type=SYSCALL msg=audit(1395174916.444:476603): arch=c000003e syscall=59 success=no exit=-13 a0=7feaddb404a0 a1=7feaddb40470 a2=7feaddb3b2d0 a3=7fffa4fe93d0 items=0 ppid=21187 pid=25396 auid=500 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=69836 comm="local" exe="/usr/libexec/postfix/local" subj=unconfined_u:system_r:postfix_local_t:s0 key=(null)

Here is the output of getsebool httpd_can_sendmail

$ getsebool httpd_can_sendmail
httpd_can_sendmail --> on

Best Answer

SELinux is pretty daunting to learn. Heck, I still don't fully understand everything. But one thing that has helped me was to install the package setroubleshoot and learn how to use the sealert and audit2allow tools. It looks at your audit log, finds what was denied, gives a basic description for why it was blocked and helps you to create rules to allow it if needed. I think it's part of the EPEL repo. Check it out.

Related Solutions

Redhat Apache fast-cgi selinux permissions

Running FastCGI your way leaves a big security hole: the PHP interpreter is run as user "httpd" (at least I can't see anything about suexec here).

We have a working setup with SELinux and PHP as FastCGI here at CentOS 6, but it was really tricky to get everything working.

A few tips for the start:

you don't need to reboot to disable/enable selinux - just use the command "setenforce 0" or "setenforce 1" :)
always try to get everything working with SELinux disabled, then enable it and have a look at audit.log

Here we go:

enable suexec
change SELinux type for php.fcgi to httpd_fastcgi_script_exec_t
your FastCGI starter (php.fcgi) should not be writable by the user owning it (otherwise he can tweak many settings and limits). Give it the "immutable" flag: chattr +i php.fcgi

suexec has some trouble with FastCGI, so we have to make it permissive:

yum install policycoreutils-python
semanage permissive -a httpd_suexec_t

Good luck!

Centos – Configure selinux to allow openldap on CentOS 6.4

If you filter the audit logs through audit2allow(1) and audit2why you'll get an approximate idea of what is happening:

#============= slapd_t ==============
allow slapd_t self:capability sys_nice;
allow slapd_t var_log_t:file { write read };
------------------------------------

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.408:3263): avc:  denied  { sys_nice } for  pid=1492 comm=slapd capability=23  scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:system_r:slapd_t:s0 tclass=capability

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.424:3264): avc:  denied  { read } for  pid=1493 comm=slapd name=log.0000000001 dev=dm-0 ino=263969 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Checking labeling

It is unlikely a label restore prevents you from starting a service if SELinux is in permissive mode. Also, why the -F switch?

To know if you have to restore the labeling of a directory or file, first find out what context a file or directory is supposed to have:

# matchpathcon /etc/openldap/
/etc/openldap   system_u:object_r:etc_t:s0

Then list its security context:

# ls -ldZ /etc/openldap/
drwxr-xr-x. root root system_u:object_r:etc_t:s0       /etc/openldap//

In this example, no further action is needed.

With regards to your issue, the problem is not labeling per se, but a missing type enforcement rule, i.e., a rule that allows a labeled process to transition from one confined domain to another, or to read files with an specific label, for example.

Creating an SELinux module

You can try to build a module that allows the slapd_t to perform the operations which appeared in the audit.log. It is probable that you need further adjustments in your code. Use audit2allow, and make for this task. All commands are very well documented in their respective manpages. The process will look roughly like this (after copying the relevant messages into audit.txt):

audit2allow -i audit.txt -m slapd -o slapd.te
make -f /usr/share/selinux/devel/Makefile load

Also, check if a bug report for the SELinux policy regarding this issue already exists.