Centos 7.3 SELinux Issues

[robbrucks]

Hey Ryan,

I just wanted to give you a heads-up that SE Linux was upgraded to a new version in Centos 7.3 and now adding new custom SE modules using the documented procedures appears to be broken... sigh

I did a fresh 7.3 install and setup, and added the socket module to let the agent talk to PG and SE Linux just ignores them. Running sealert after adding the module throws tons of errors.

In a few posts people mentioned that it is only a problem on fresh installs, apparently some critical components were left out of the new SE package that were in the old one, so upgrading works fine since the old version of the files are still there.

Google searches don't offer a workaround, but others are having problems with it too. Maybe they'll fix it quickly.

Yay.

--Rob

[robbrucks]

After doing some research I found that they introduced a bug in SELinux 2.5 on Centos/RHEL 7.3: Bug 1406328

I was using the standard "sealert -a /var/log/audit/audit.log" command to find the problem, then copying and pasting the commands it generated to add the policy.

But I found that the "ausearch" command was adding junk characters into the audit log record it finds. This was causing all kinds of errors for SELinux.

The workaround method that I used was to NOT use "ausearch" that sealert now advises under 2.5, but rather to use the old grep method instead like the older pre 2.5 sealert versions:

Broken:

# ausearch -c 'zabbix_agentd' --raw | audit2allow -M my-zabbixagentd
# semodule -i my-zabbixagentd.pp

Fixed:

# grep zabbix_agentd /var/log/audit/audit.log | audit2allow -M my-zabbixagentd
# semodule -i my-zabbixagentd.pp

Worked like a charm.

--Rob

[robbrucks]

Under the new SELinux the postgres socket file no longer has the file context it used to have (postgresql_var_run_t), but instead appears to now have the default tmp_t context.

# ls -lZ /tmp/.s.PGSQL.5432
srwxrwxrwx. postgres postgres system_u:object_r:tmp_t:s0       /tmp/.s.PGSQL.5432

So for SELinux on RHEL/Centos 7.3 and higher the module that now needs to be created is:

module zabbix_agent_postgres 1.0;

require {
	type tmp_t;
	type zabbix_agent_t;
	class sock_file write;
}

#============= zabbix_agent_t ==============

#!!!! WARNING: 'tmp_t' is a base type.
allow zabbix_agent_t tmp_t:sock_file write;

But I bet at some point the PostgreSQL developers will fix the problem and put back the original file context.

[cavaliercoder]

I'm considering packaging an semodule, zabbix_module_pgsql.pp that includes all the required allow statements for libzbxpgsql to run correctly on an Enforcing machine. I'm not sure of best practice for installing/uninstalling semodules via RPM though. Given your knowledge, does this sound advisable or should we rely on upstream semodules?

[robbrucks]

TBH I have absolutely no idea whether or not that's a good thing or how to do it.

Honestly I'd like to see someone add an upsteam boolean to allow the Zabbix agent to talk to PG sockets (similar to Apache booleans), so it can just be enabled as needed. But I have no idea how to get it added upstream, whether that's something we can get the Zabbix team to add or if the SE Linux team would have to add it. SE Linux seems to be in a bit of disarray after their most recent upgrade, lots of things are buggy or just don't work (like the agent needing an "rlimit" rule now).

A few months ago I spent two days trying to figure out how to package an SE module and found that you can't reliably package the module itself, due to differences in versions of SE libraries installed on servers. To be reliable I had to compile it from source on every install.

I ended up using Ansible to copy the "te" file onto each server and compiling and installing it manually.

I love SE Linux and use it all the time, but I hate not having a reliable way to include an SE module in install RPMs and have it always work.

Googling just didn't give me much info on how to accomplish it.

I wish I had a better answer for you.

On Fri, May 5, 2017 at 10:23 AM, Ryan Armstrong [email protected] wrote:

I'm considering packaging an semodule, zabbix_module_pgsql.pp that includes all the required allow statements for libzbxpgsql to run correctly on an Enforcing machine. I'm not sure of best practice for installing/uninstalling semodules via RPM though. Given your knowledge, does this sound advisable or should we rely on upstream semodules?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cavaliercoder/libzbxpgsql/issues/78#issuecomment-299494693, or mute the thread https://github.com/notifications/unsubscribe-auth/AOBRoOcDQZx5m2P_sU-3zmchj5plfTn7ks5r2z7dgaJpZM4MLk-w .

[cavaliercoder]

The rlimit issue may provide some insight into how best to request this feature. For reference:

• Zabbix issue
• Patch request
• Accepted patch
• RHEL issue
• Fedora issue