Re: need help interpreting ausearch results

Stefano, I assume your rules are file watches. Yes, on the surface, it looks like a service user, lanogbar, is running a php application which has make the chmod system call making the change to 777 (ie a1=1ff in the second event shown). You could check the process id's (the one which does the chmod - pid = 8804, or the parent process id - ppid = 27717) although these might be temporary processes ... perhaps you could turn on execution audit -a exit,always -F arch=b32 -S execve -k cmds -a exit,always -F arch=b64 -S execve -k cmds perhaps also specific chmods also ... -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -S chown -S fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! =4294967295 -k perm_mod -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -S chown -S fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! =4294967295 -k perm_mod Also, as Peter suggests it does help if you present the output from ausearch -i rather than the raw data from /var/log/audit/audit.log. On Sun, 2013-12-22 at 09:05 -0800, Peter Moody wrote: > What's the actual rule? On my system, syscall 88 is either symlink (64 bit) or reboot (32 bit). > > On Sat, Dec 21 2013 at 04:48, Stefano Schiavi wrote: >> Hello, >> >> Could anyone help with this? I really don't know where else to ask. >> >> Thank you very much. >> Stefano >> >> >> On 12/15/13, 12:19 AM, Stefano Schiavi wrote: >>> Hello, >>> >>> Thank you Steve and all for keeping up the great work here. >>> >>> Some time ago I setup some audit rules to monitor what would change the permissions of the >>> public_html directory since we found that once in a while it would change to 777 out of the >>> blue. >>> >>> It happened again yesterday and I believe these parts of the log represent when the issue >>> happened: >>> >>> type=PATH msg=audit(1386933561.795:7958476): item=2 name="./www" inode=4980752 dev=08:08 >>> mode=0120777 ouid=501 ogid=501 rdev=00:00 >>> type=PATH msg=audit(1386933561.795:7958476): item=1 name="./" inode=4980737 dev=08:08 >>> mode=040711 ouid=501 ogid=501 rdev=00:00 >>> type=PATH msg=audit(1386933561.795:7958476): item=0 name="public_html" >>> type=CWD msg=audit(1386933561.795:7958476): cwd="/home/lanogbar" >>> type=SYSCALL msg=audit(1386933561.795:7958476): arch=c000003e syscall=88 success=yes exit=0 >>> a0=1306d160 a1=1306d200 a2=11 a3=0 items=3 ppid=18728 pid=18731 auid=0 uid=501 gid=501 >>> euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=117304 comm="gtar" >>> exe="/bin/tar" key="lanogbar-www" >>> >>> >>> This is just a guess though and I can not be sure as I have no experience parsing the >>> logs. Looking through with the I flag we can see the following:: >>> >>> type=PATH msg=audit(12/13/2013 15:00:03.759:7970202) : item=0 >>> name=/home/lanogbar/public_html/ inode=4980744 dev=08:08 mode=dir,750 ouid=lanogbar >>> ogid=nobody rdev=00:00 >>> type=CWD msg=audit(12/13/2013 15:00:03.759:7970202) : cwd=/home/lanogbar/public_html >>> type=SYSCALL msg=audit(12/13/2013 15:00:03.759:7970202) : arch=x86_64 syscall=chmod >>> success=yes exit=0 a0=1585e520 a1=1ff a2=2f a3=146c1d40 items=1 ppid=27717 pid=8804 auid=root >>> uid=lanogbar gid=lanogbar euid=lanogbar suid=lanogbar fsuid=lanogbar egid=lanogbar >>> sgid=lanogbar fsgid=lanogbar tty=(none) ses=117304 comm=php exe=/usr/bin/php >>> key=lanogbar-public_html >>> >>> Do you think this is relevant? >>> If so it would seem a php script was responsible. >>> >>> Would you have any suggestion on how to identify the script? >>> >>> Thank you very much for the very valuable help. >>> Kind regards, >>> Stefano >> -- >> Linux-audit mailing list >> Linux-audit(a)redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit > -- > Linux-audit mailing list > Linux-audit(a)redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit