1

I'm hardly trying to correctly use selinux keeping it in enforced mode, but very often I encounter issues with it causing our application to work improperly.

Our web application is java backend and angular front end, deployed on tomcat and apache httpd, the backend use lucene as a search engine which create a file into a filesystem folder every time a re-index is performed. Oh yes, the server is CentOS7 if this matters.

for the growth of others I say that reading the subhuman SELinux log /var/log/audit/audit.log is useless, and you must before traslate it into human using the command:

sealert -a /var/log/audit/audit.log > /var/log/audit/audit_human_readable.log

In my case the log was saying the follow:

SELinux is preventing /whatever/jre/bin/java from write access on the file /opt/whatever/write.lock

and suggesting to fix the issue by:

If you want to allow java to have write access on the write.lock file
Then you need to change the label on /opt/whatever/write.lock
Do
# semanage fcontext -a -t FILE_TYPE '/opt/whatever/write.lock'
where FILE_TYPE is one of the following: afs_cache_t, initrc_tmp_t, pki_common_t, pki_ra_log_t, pki_tomcat_cert_t, pki_tomcat_etc_rw_t, pki_tomcat_log_t, pki_tomcat_var_lib_t, pki_tps_log_t$
Then execute:
restorecon -v '/opt/whatever/write.lock'

Which looks like a pretty nice and complete suggestion, except that in the past I already executed this suggestion, but on the parent folder hoping this would be applied on childs too, but the issue is still there.

I believe the issue still exists because Lucene through the java process often re-create the write.lock file, very often, everytime a new reindex is performed, and that's mean everytime a new file is uploaded into webapplication which is part of the main functionalities of it. And recreating this file the SElinux context is not inherited correctly.

How can I configure, that every file created under a certain folder, will inherit a specific SElinux context from it's parent directory?

EDIT: (audit.log)

type=AVC msg=audit(1528202320.971:33808): avc:  denied  { write } for  pid=31394 comm="java" name="index" dev="dm-0" ino=57073 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
type=AVC msg=audit(1528202320.971:33808): avc:  denied  { remove_name } for  pid=31394 comm="java" name="write.lock" dev="dm-0" ino=57076 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
type=AVC msg=audit(1528202320.971:33808): avc:  denied  { unlink } for  pid=31394 comm="java" name="write.lock" dev="dm-0" ino=57076 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1528202320.971:33808): arch=c000003e syscall=87 success=yes exit=0 a0=7f4a549d8db0 a1=7f4a8c92e1c8 a2=0 a3=3536353030303030 items=2 ppid=1 pid=31394 auid=4294967295 uid=91 gid=91 euid=91 suid=91 fsuid=91 egid=91 sgid=91 fsgid=91 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre/bin/java" subj=system_u:system_r:tomcat_t:s0 key=(null)

EDIT 2: (ps -auxZ)

# ps -auxZ | grep tomcat
system_u:system_r:tomcat_t:s0   tomcat    1026  1.2 30.7 9637644 7535952 ?     Ssl  May09 514:38 /usr/lib/jvm/jre/bin/java -(and so on)
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 31648 0.0  0.0 112712 976 pts/0 S+ 14:58   0:00 grep --color=auto tomcat
  • 2
    Please also provide the raw output of audit.log file (or use something like ausearch -m avc -i) – Bigon Jun 5 '18 at 10:45
  • thank you for the answer, updated the question whit new info – lese Jun 5 '18 at 12:41
  • If I understand that well the java process is labeled as tomcat_t? (you can check that with ps auxZ) – Bigon Jun 5 '18 at 12:44
  • yes exactly man updating the question – lese Jun 5 '18 at 12:59
2

I believe the main problem is that your java installation is not properly labeled.

The easiest way of fixing this is to install the Oracle JRE/JDK RPM instead of using the tarball/zip file, or at least install the java directory in /usr/java

Otherwise you should probably label the /whatever/jre/bin directory and all the content as bin_t for that you can see tonioc reply in this thread and do

# semanage fcontext -a -t bin_t "/whatever/jre/bin(/.*)?"
# restorecon -R -v /whatever/jre/bin

Edit, you might want to do that as well:

# semanage fcontext -a -t lib_t "/whatever/jre/lib(/.*)?"
  • Thank you for your usefull replies, just to be sure, the following will not work? semanage fcontext -a -t tomcat_t "/opt/whatever(/.*)?" && semanage fcontext -a -t tomcat_t "/opt/whatever(/.*)?" Just wondering because I believe the issue is the context of /opt/whatever/write.lock file is wrong since recreated each time very often – lese Jun 5 '18 at 14:10
  • PS: my java installation was very standard yum install java-1.8.0-openjdk.x86_64 tomcat.noarch using the default centOS 7 repositories – lese Jun 5 '18 at 14:12
  • no, tomcat_t should only be used by the scripts starting tomcat, not by the java executable itself – Bigon Jun 5 '18 at 15:13
1

Supposing you want files in /opt/whatever to get context whatever_t , the commands would be:

# semanage fcontext -a -t whatever_t "/opt/whatever(/.*)?"
# restorecon -R -v /opt/whatever

This should do what you expect. See man semanage-fcontext

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.