SELinux fixes/workarounds for RHEL/CentOS 5/6 & Plesk 10

[bluik]

While setting up RHEL and CentOS servers, both 5 and 6, with Plesk 10 I have come across a lot of SELinux policy violations which means Plesk or its components will not work if SELinux is set to enforcing mode (`/usr/sbin/getenforce` shows 1).
Symptoms are 'weird' access denied errors while permissions look OK and "avc" lines showing up in /var/log/audit/audit.log and/or some other place where SELinux logs go (could be /var/log/messages with audispd/setroubleshootd).
As someone else on this forum said: "you are a fool if you disable SELinux". So do not just disable enforcing mode or SELinux! Get Parallels to fix the policy!!

Some of my fixes/workarounds:

PHP as mod_fcgi: PHP Session directory /var/lib/php/session & files in it not writable

type=AVC msg=audit(1:1): avc: denied { search } for pid=1 comm="php-cgi" name="session" dev=sda1 ino=1 scontext=root:system_r:httpd_sys_script_t:s0 tcontext=system_ubject_r:httpd_var_run_t:s0 tclass=dir
type=AVC msg=audit(1:1): avc: denied { write } for pid=1 comm="php-cgi" name="session" dev=sda1 ino=1 scontext=root:system_r:httpd_sys_script_t:s0 tcontext=system_ubject_r:httpd_var_run_t:s0 tclass=dir
type=AVC msg=audit(1:1): avc: denied { add_name } for pid=1 comm="php-cgi" name="sess_asdf" scontext=root:system_r:httpd_sys_script_t:s0 tcontext=system_ubject_r:httpd_var_run_t:s0 tclass=dir
type=AVC msg=audit(1:1): avc: denied { create } for pid=1 comm="php-cgi" name="sess_asdf" scontext=root:system_r:httpd_sys_script_t:s0 tcontext=rootbject_r:httpd_var_run_t:s0 tclass=file

- Ensure owner/group is apachesacln, mode 770.
- Could be fixed by picking up an existing context `sesearch` that has correct permissions; `chcon` is the quick fix but does not survive relabeling, better way is to create specification for the file context:

`/usr/sbin/semanage fcontext -a -t httpd_sys_content_t '/var/lib/php/session(/.*)?'`

- Or more correctly by creating a completely new SELinux type for the session directory; an early work-in-progress version of this is in another thread with my various ramblings. The best solution would be to create new very restricted domain for FastCGI but it is a lot of work. I am sure it could improve the security if done properly (disable /proc for LFI for example). FastCGI should need less permissions than Apache.
- Or just create a policy based on `audit2allow` that allows access from httpd_sys_script_t source process type to the httpd_var_run_t file type:

module plesk-phpsession 1.6;

require {
type httpd_sys_script_t;
type httpd_var_run_t;
class dir { search write add_name remove_name };
class file { create read write lock unlink getattr };
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_var_run_t:dir { search write add_name remove_name };
allow httpd_sys_script_t httpd_var_run_t:file { create read write lock unlink getattr };

- Note: For RHEL6/CentOS6 you need to add " open" at the two locations after "getattr". Giving access to httpd_var_run_t might be a security risk which is why new type would be better. Anyhow httpd_t (PHP run as module) has this permission so it should be fine.

ClamAV (from atomic): can't freshclam or use JIT due to RWX mmap

type=AVC msg=audit(1:1): avc: denied { execmem } for pid=1 comm="clamd" scontext=system_u:system_r:clamd_t:s0 tcontext=system_u:system_r:clamd_t:s0 tclass=process

- It should fallback to interpreter mode which is slow.
- It might not be a good idea to enable the below because it opens a door for exploits. I rather opted for interpreter mode and disabled JIT for more security. Complex security issue, see discussion for full security implications: https://bugzilla.redhat.com/show_bug.cgi?id=573191
- Simple `audit2allow`:

module clamdexecmem 1.0;

require {
type clamd_t;
class process execmem;
}

#============= clamd_t ==============
allow clamd_t selfrocess execmem;

PSA Panel: Log file context wrong

type=AVC msg=audit(1:1): avc: denied { append } for pid=1 comm="httpd" path="/usr/local/psa/tmp/rc_actions.log" dev=sda1 ino=1 scontext=user_u:system_r:httpd_t:s0 tcontext=rootbject_r:usr_t:s0 tclass=file

- The panel automatic restart (?) system cannot update its own logfile.
- "append" to the file is also required by named_t. The workaround below does not fix it. There is no common appropriate file context that could be used for both httpd_t and named_t. Proper solution would be a new type. Perhaps after I get this batch of servers to production (with SELinux enabled) I try to find time to create proper single policy package that fixes most of these.
- Partial fix by changing file context from usr_t to httpd_log_t:

`/usr/sbin/semanage fcontext -a -f -- -t httpd_log_t '/usr/local/psa/tmp/rc_actions\.log'`

Postfix on sending mail: /usr/local/psa/handlers/spool invalid fcontext/policy

type=AVC msg=audit(1:1): avc: denied { read } for pid=1 comm="postalias" path="/usr/local/psa/handlers/spool/mlfi.asdf" dev=sda1 ino=1 scontext=user_u:system_rostfix_master_t:s0 tcontext=user_ubject_r:mail_spool_t:s0 tclass=file

- Don't know what to do with this. Plesk has specified a file context:

/usr/local/psa/handlers/spool(/.*)? all files system_ubject_r:mail_spool_t:s0

So either the read is not supposed to happen and a dontaudit policy should be created; or the type postfix_master_t should be allowed allowed access to type mail_spool_t. This could be the most obvious bug in Plesk SELinux policy. I hope someone could clarify and I would not need to trace the process.

Postfix: Problem with fifo, no solution
- For this one I also am unsure what to do since I cannot find the inode of the fifo in the error. `find / -inum` does not find it?
- I am not familiar enough with Postfix to even start on this one. It could be possible to just `audit2allow` it but what are the security implications of doing so blindly?

type=AVC msg=audit(1:1): avc: denied { read } for pid=1 comm="postdrop" path="pipe:[1]" dev=pipefs ino=1 scontext=system_u:system_rostfix_postdrop_t:s0 tcontext=system_u:system_rostfix_master_t:s0 tclass=fifo_file
type=AVC msg=audit(1:1): avc: denied { write } for pid=1 comm="postdrop" path="pipe:[1]" dev=pipefs ino=1 scontext=system_u:system_rostfix_postdrop_t:s0 tcontext=system_u:system_rostfix_master_t:s0 tclass=fifo_file

I have said it before and I say it again. Plesk should be secure by default and actually work with sane security settings on the OS side (SELinux enabled).

As usual all this comes with no warranty whatsoever, no liability etc. Use at your own risk.

 

[bluik]

How to use the SELinux policies:
save to a file, using ex.te here

`/usr/bin/checkmodule -Mm ex.te -o ex.mod`
`/usr/bin/semodule_package -o ex.pp -m ex.mod`
`/usr/sbin/semodule -i ex.pp`

And after file context changes with semanage fcontext, do a `restorecon -vr` on the directory/file.

 

[bluik]

Subscriptions that need to send mail cannot write to log files
- Needs investigation

type=AVC msg=audit(1:1): avc: denied { append } for pid=1 comm="sendmail" path="/var/www/vhosts/example2.com/statistics/logs/error_log" dev=sda1 ino=1 scontext=root:system_r:system_mail_t:s0 tcontext=system_ubject_r:httpd_sys_content_t:s0 tclass=file
type=AVC msg=audit(1:1): avc: denied { append } for pid=1 comm="postdrop" path="/var/www/vhosts/example.com/statistics/logs/access_log" dev=sda1 ino=1 scontext=root:system_rostfix_postdrop_t:s0 tcontext=rootbject_r:httpd_sys_content_t:s0 tclass=file

This could be a file descriptor leak because I just saw it happen to all of the few test domains/subscriptions on this server.