8

I know I have an issue with SElinux. So I am following a tutorial that will help me understand the nature of the file access problems I am having. That was I can still have SElinux enforce as supposed to just disabling it.

Basically I have set SElinux set to permissive mode, for testing, and done a file action that would fail while it is enforcing. That way I will see what the message in the log looks like. Such a line looks like this:

type=USER_CMD msg=audit(1452912989.069:324790): pid=66581 uid=1001 auid=1001 ses=1352 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/srv/dpca/www" cmd=7461696C202F7661722F6C6F672F61756469742F61756469742E6C6F67 terminal=pts/0 res=success'

Now since I am really new to this I refered to the tutorial and how it talks about getting audit2why to lay this out for me. 

[matt@localhost www]$ sudo grep 1452912989.069:324790 /var/log/audit/audit.log | audit2why Nothing to do

The grep does return the correct text. However audit2why appears to be returning "Nothing to do".

Is there something fundamental that I am doing wrong? End of the day I am trying to figure out what context to assign to some NGINX directories. I am sure I can just look them up but I wanted also to understand what I am doing as supposed to just running commands I see on the internet.

In case you are curious this is a small snippet of my web root directory context

drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 administrator drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 bin drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 cache
Improve this question
3
  • You're feeding a type=USER_CMD log entry into audit2why, when audit2why only translates AVCs. Commented Jan 23, 2016 at 4:05
  • Hey, Matt! You're first mistake is wanting to understand what SELinux is doing. You can forget about your woodworking projects because this will take up the rest of your free time. Commented Mar 13, 2016 at 15:34
  • The link to the tutorial mentioned in the question is dead. For posterity, an archived copy of it can be found here: web.archive.org/web/20160315083542/https://www.nginx.com/blog/… Commented Aug 6, 2024 at 15:20

2 Answers 2

Reset to default
4

Note: I am still interested in an answer to my issue but I did want to post a work-around that I am using that gives just as useful information if audit2why was working how I would have expected.

Under the Howto for SELinux on CentOS.org there is a troubleshooting section. Therein is talks about how to use sealert to give human readable information parsed from the log "/var/log/audit/audit.log". So simply running

sudo sealert -a /var/log/audit/audit.log > ~/logfile.txt

allowed me to read the information I wanted and get suggestions about the proper security context for my web directories. 

SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images. ***** Plugin httpd_write_content (92.2 confidence) suggests *************** If you want to allow php-fpm to have write access on the images directory Then you need to change the label on '/srv/dpca/www/images' Do # semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images' # restorecon -v '/srv/dpca/www/images'

Again, if someone knows about my original question about audit2why I would still like to know.

Improve this answer
1

/var/log/audit/audit.log is a binary file. You can grep for the content with

grep -a AVC /var/log/audit/audit.log | audit2why
Improve this answer
1
  • Thank you very much! Commented Sep 15, 2021 at 10:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.