2

I'm trying to figure out how to log/track when a user gets a Permission denied notice after attempting to access a file. I've read that adding a rule to /etc/audit/audit.rules can accomplish this.

The only suggestion that I've seen mentioned appears to not work as intended. Or, at least, it does not do what I would like. It very well may work the way it is written. The rule is

-a always,exit -F arch=b64 -S open -F success!=0

Actually, the suggestion at the link above does not include the arch option. I had to add that.

When tailing /var/log/audit/audit.log I'm seeing everything that says success=yes. This includes when I click a window and change focus or enter key combinations to change between window functions. What I'm not seeing is anything relating to Permission denied to include success=no entries or anything about a specific file that I attempt to open knowing I don't have permissions on it.

All I can say definitively is that when I grep for success=no in /var/log/audit/audit.log nothing is returned.

What should the rule be? Or better yet, is this even actually possible? Is the solution above incorrect?

1 Answer 1

7

I've been tooling around and found that if I use success!=1 then audit.log will display entries that indicate success=no. This seems counter-intuitive to me since a non-zero exit code typically indicates a failure of some sort but !=1 could be anything including other failure exit codes as well as a success (0). Interestingly, though, those don't show up.

An additional problem is that it does not indicate which file had the failed access. Instead, it only lists the command that ran when the failed exit code was returned. In my case, I was running cat /etc/shadow. So, instead of seeing

type=SYSCALL msg=audit(1438754257.463:11451): arch=c000003e syscall=2 success=no exit=-13 a0=7ffea511f35f a1=0 a2=1ffffffffffe0000 a3=0 items=1 ppid=1650 pid=5489 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts0 ses=1 comm="cat" exe="/usr/bin/cat" key="access"
type=CWD msg=audit(1438754257.463:11451):  cwd="/home/msnyder"
type=PATH msg=audit(1438754257.463:11451): item=0 name="/etc/shadow" inode=1131047 dev=00:20 mode=0100640 ouid=0 ogid=15 rdev=00:00 nametype=NORMAL

I would only see

type=SYSCALL msg=audit(1438752096.223:4952): arch=c000003e syscall=2 success=yes exit=3 a0=7f77d575c057 a1=80000 a2=1 a3=22 items=1 ppid=1650 pid=4873 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts0 ses=1 comm="cat" exe="/usr/bin/cat" key=(null)
type=CWD msg=audit(1438752096.223:4952):  cwd="/home/msnyder"

I then looked at the audit.rules manpage. Eureka! The answer was in there all along:

-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -F key=access
-a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -F key=access

Those two rules combined solve the problem. Not only will it log the failed file access, but it will also log which file the access was attempted on. This results in the first three log entries above which includes the file name.

1
  • 1
    You can use ausearch --interpret --exit 13 (choose your exit code) to interpret the codes for you and print them in a nicer way for human consumption.
    – user158513
    Jul 12, 2016 at 20:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .