2

My issue is fairly similar to this one: I have a Java application running on Rhel 8 that relies on an sqlite-jdcb driver. Unlike in that issue, my issue isn't with my filesystem being mounted with noexec. Instead, its with fapolicyd prohibiting java from executing the driver:

Aug 02 11:36:40 hostname cerebro[3210818]: /opt/cerebro/sqlite-3.34.0-47390f7e-7dd5-45d7-9a01-0635f335df40-libsqlitejdbc.so (Operation not permitted)
Aug 02 11:36:42 hostname cerebro[3210818]: /opt/cerebro/sqlite-3.34.0-cb416389-64b7-4ed6-9e52-5c710ec85a6c-libsqlitejdbc.so (Operation not permitted)

Normally, I would use the fapolicyd-cli command to add the driver file to the fapolicyd trust list, but each time the application starts, the JDBC driver file has a unique filename, so adding an existing file isn't a viable option. Note the hexidecimal characters above - those are different at each application startup.

How do I handle this situation?

cutrightjm
  • 344
  • 2
  • 13
ADS103
  • 116
  • 1
  • 6

1 Answers1

0

You should be able to do this based on the files mime type and path. Below is an example.

I create a file, myfile, and try to run it. I observe it's being blocked by fapolicyd:

[localuser@server ~]$ echo 'echo hello' > myfile-1
[localuser@server ~]$ chmod +x ./myfile-1
[localuser@server ~]$ ./myfile-1
bash: ./myfile-1: Operation not permitted
[localuser@server ~]$

You have two options to view a useful log output for fapolicyd debugging:

  • one, systemctl stop fapolicyd.service and then run fapolicyd-cli debug-deny while waiting for a block
  • two, modify any deny statements in /etc/fapolicyd/rules.d/ to be deny_log or deny_syslog. To make this change take effect, fapolicyd-cli --update; systemctl restart fapolicyd

Once you are getting useful block statements, you should see a message like this:

Aug 8 01:20:15 server.nix.turnerfarms.net fapolicyd[9083]: rule=16 dec=deny_log perm=execute auid=0 pid=9087 exe=/usr/bin/bash : path=/home/localuser/myfile-1 ftype=text/plain trust=0

Above, we see that rule 16 blocked the file at /home/localuser/myfile-1 from running. If we take a look at rule 16, we see it is this rule:

[root@server rules.d]# fapolicyd-cli --list | grep '^16
16. deny_log perm=execute all : all

The reason the rule number matters is that fapolicyd trust rules are processed lexically, meaning if we add a rule for an application it has to be in a file that comes before the one with the block in it.

Identify the file with the block:

[root@server rules.d]# grep -r 'deny_log perm=execute' /etc/fapolicyd/rules.d/
/etc/fapolicyd/rules.d/90-deny-execute.rules:deny_log perm=execute all : all

Since the name of myfile-* will always change, we can allow it based on mime type. If you look at the deny that was logged earlier, you will see that subject is /usr/bin/bash and the mimetype is text/plain

Create a new rule that precedes 90, let's say 89-allow-myfiles.rules:

allow perm=execute exe=/usr/bin/bash : dir=/home/localuser/ ftype=text/plain

Notify fapolicyd of a policy update, and restart the service

fapolicyd-cli --update && systemctl restart fapolicyd

Replace SELinux contexts on our new files:

restorecon -Rv /etc/fapolicyd/rules.d/

And you should be good now:

[localuser@server ~]$ ./myfile-1
hello
[localuser@server ~]$ ./myfile-2
hello

You can customize the subject and object of the rule as much as you would like to improve security.

TL;DR: You can whitelist applications with a rule, which has a more advanced syntax than a trust. There are various configuration options, including mime type, uid, gid, and path. A simple way to do it is to find the mime type of your application and write a rule that whitelists that mime type in a given folder.

References:

cutrightjm
  • 344
  • 2
  • 13