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