Discussion:
Excluding few executable from audit.rules in redhat6.5
(too old to reply)
Tilden Doran D
2014-11-17 15:02:12 UTC
Permalink
Hi All,

I am new to Redhat Audit logging.
Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and SELinux is enabled.

We are getting lots of logs messages in /var/log/messages.

type=SYSCALL msg=audit(1416235337.083:2109222): arch=c000003e syscall=90 success=yes exit=0 a0=7f52ae9f1a20 a1=3ff a2=ffffffffffffff88 a3=fffffffffffffff0 items=1 ppid=1 pid=46859 auid=500 uid=345 gid=345 euid=345 suid=345 fsuid=345 egid=345 sgid=345 fsgid=345 tty=(none) ses=28 comm="ohasd.bin" exe="/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod"
type=PATH msg=audit(1416235337.083:2109222): item=0 name="/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703" inode=4718596 dev=fd:00 mode=041755 ouid=345 ogid=345 rdev=00:00 obj=unconfined_u:object_r:usr_t:s0 nametype=NORMAL


Later we found and removed message type "CWD", but still we are getting lot of logs.

And also found that the below mentioned executable are creating the problem.

13351. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500 1599360
13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle (none) ? 500 1599354
13353. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500 1599361

Can you please help me in excluding the above mentioned Executable `s in the audit. rules files .

Thanks in advance.


--Tilden
Ericsson AB
Steve Grubb
2014-11-17 15:30:38 UTC
Permalink
Post by Tilden Doran D
I am new to Redhat Audit logging.
Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and SELinux is enabled.
We are getting lots of logs messages in /var/log/messages.
type=SYSCALL msg=audit(1416235337.083:2109222): arch=c000003e syscall=90
success=yes exit=0 a0=7f52ae9f1a20 a1=3ff a2=ffffffffffffff88
a3=fffffffffffffff0 items=1 ppid=1 pid=46859 auid=500 uid=345 gid=345
euid=345 suid=345 fsuid=345 egid=345 sgid=345 fsgid=345 tty=(none) ses=28
comm="ohasd.bin" exe="/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod"
type=PATH msg=audit(1416235337.083:2109222): item=0
name="/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703"
inode=4718596 dev=fd:00 mode=041755 ouid=345 ogid=345 rdev=00:00
obj=unconfined_u:object_r:usr_t:s0 nametype=NORMAL
Later we found and removed message type "CWD", but still we are getting lot of logs.
And also found that the below mentioned executable are creating the problem.
13351. 11/16/2014 18:11:34
/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500 1599360
13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle
(none) ? 500 1599354 13353. 11/16/2014 18:11:34
/opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500 1599361
Can you please help me in excluding the above mentioned Executable `s in
the audit. rules files .
Well, what do you really want to do? In general, I'd look at the original
auditing rule to see if its scope can be narrowed. In this case, it appears
that you are wanting all calls to chmod. Why? Are you more concerned with
failed calls to chmod, meaning a user is trying to change system files? Are
system daemons calling chmod OK? Or do you really want everything? Or do you
want no events at all for that daemon no matter what the syscall?

The event you are showing is that app successfully making a directory world
writable/readable. Its setting the sticky bit, so its "safe."

-Steve
LC Bruzenak
2014-11-17 16:14:59 UTC
Permalink
Post by Steve Grubb
Well, what do you really want to do? In general, I'd look at the original
auditing rule to see if its scope can be narrowed. In this case, it appears
that you are wanting all calls to chmod. Why? Are you more concerned with
failed calls to chmod, meaning a user is trying to change system files? Are
system daemons calling chmod OK? Or do you really want everything? Or do you
want no events at all for that daemon no matter what the syscall?
The event you are showing is that app successfully making a directory world
writable/readable. Its setting the sticky bit, so its "safe."
I think this is auditing because the supplied STIG rules specify it.
The "perm_mod" key is the hint. You probably do not want to remove this
rule for all chmod syscalls.

You cannot exclude an executable itself from the rule set by name.
The "exclude" option only applies to event types.

You could exclude it by type, except it is running as a generic
unconfined_t.
Perhaps it can be mitigated by "-F path !=<path>" or something similar.
Check the auditctl man page for options.

LCB
--
LC (Lenny) Bruzenak
***@magitekltd.com
Steve Grubb
2014-11-17 16:42:17 UTC
Permalink
Post by LC Bruzenak
Post by Steve Grubb
Well, what do you really want to do? In general, I'd look at the original
auditing rule to see if its scope can be narrowed. In this case, it appears
that you are wanting all calls to chmod. Why? Are you more concerned with
failed calls to chmod, meaning a user is trying to change system files? Are
system daemons calling chmod OK? Or do you really want everything? Or do
you want no events at all for that daemon no matter what the syscall?
The event you are showing is that app successfully making a directory world
writable/readable. Its setting the sticky bit, so its "safe."
I think this is auditing because the supplied STIG rules specify it.
The "perm_mod" key is the hint. You probably do not want to remove this
rule for all chmod syscalls.
OK. Missed that. Then looking at the rule, it has an exclusion for daemons
because its only concerned with auid>=500. So, that means that someone
restarted the daemon by hand rather than rebooting the system

If a temporary fix is needed until the systems is rebooted, then one could do
this:

auditctl -A exit,never -S chmod -F uid=345

That will get rid of all chmod calls by user account 345. Notice the capital
A, this places the rule at the beginning because the rule that matches first
wins. I would not make that a permanent rule, just a workaround until it can
be rebooted. But also note that it could trigger other rules because it has a
user's auid.
Post by LC Bruzenak
You cannot exclude an executable itself from the rule set by name.
The "exclude" option only applies to event types.
You could exclude it by type, except it is running as a generic
unconfined_t.
Yeah, as a daemon it should be something else. Unconfined is only from a user
session. Daemons get initrc_t when they are unknown.

-Steve
Steve Grubb
2014-11-17 17:09:10 UTC
Permalink
Post by Steve Grubb
Post by LC Bruzenak
Post by Steve Grubb
Well, what do you really want to do? In general, I'd look at the original
auditing rule to see if its scope can be narrowed. In this case, it appears
that you are wanting all calls to chmod. Why? Are you more concerned with
failed calls to chmod, meaning a user is trying to change system files? Are
system daemons calling chmod OK? Or do you really want everything? Or do
you want no events at all for that daemon no matter what the syscall?
The event you are showing is that app successfully making a directory world
writable/readable. Its setting the sticky bit, so its "safe."
I think this is auditing because the supplied STIG rules specify it.
The "perm_mod" key is the hint. You probably do not want to remove this
rule for all chmod syscalls.
OK. Missed that. Then looking at the rule, it has an exclusion for daemons
because its only concerned with auid>=500. So, that means that someone
restarted the daemon by hand rather than rebooting the system
If a temporary fix is needed until the systems is rebooted, then one could
auditctl -A exit,never -S chmod -F uid=345
A correction is in order, this likely needs arch fields to be added. It should
have been:

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345
auditctl -A exit,never -F arch=b64 -S chmod -F uid=345

-Steve
Post by Steve Grubb
That will get rid of all chmod calls by user account 345. Notice the capital
A, this places the rule at the beginning because the rule that matches
first wins. I would not make that a permanent rule, just a workaround until
it can be rebooted. But also note that it could trigger other rules because
it has a user's auid.
Post by LC Bruzenak
You cannot exclude an executable itself from the rule set by name.
The "exclude" option only applies to event types.
You could exclude it by type, except it is running as a generic
unconfined_t.
Yeah, as a daemon it should be something else. Unconfined is only from a
user session. Daemons get initrc_t when they are unknown.
-Steve
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit
Tilden Doran D
2014-11-18 10:22:55 UTC
Permalink
Hi

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345

we would require a permanent fix. If UID=345 is used, I believe that all auditing functionality will not work for user ID=345, I mean if the userId(345) is logging in manually to the system and does some operation that will also be exclude. We want User inventions logs messages to be captured but exclude the System generated logs.

To be more detail.

Ohasd.bin process is started by the user( while starting the database process) we want to captured this log.
But after that the ohasd.bin process is running in background and it does lot of read write operations, we don't want those logs.

Can you please let us know the way forward.


thanks
Tilden


-----Original Message-----
From: linux-audit-***@redhat.com [mailto:linux-audit-***@redhat.com] On Behalf Of Steve Grubb
Sent: Monday, November 17, 2014 10:39 PM
To: linux-***@redhat.com
Subject: Re: Excluding few executable from audit.rules in redhat6.5
Post by Steve Grubb
Post by LC Bruzenak
Post by Steve Grubb
Well, what do you really want to do? In general, I'd look at the
original auditing rule to see if its scope can be narrowed. In
this case, it appears that you are wanting all calls to chmod.
Why? Are you more concerned with failed calls to chmod, meaning a
user is trying to change system files?
Are
system daemons calling chmod OK? Or do you really want everything?
Or do you want no events at all for that daemon no matter what the syscall?
The event you are showing is that app successfully making a
directory world writable/readable. Its setting the sticky bit, so
its "safe."
I think this is auditing because the supplied STIG rules specify it.
The "perm_mod" key is the hint. You probably do not want to remove
this rule for all chmod syscalls.
OK. Missed that. Then looking at the rule, it has an exclusion for
daemons because its only concerned with auid>=500. So, that means that
someone restarted the daemon by hand rather than rebooting the system
If a temporary fix is needed until the systems is rebooted, then one
auditctl -A exit,never -S chmod -F uid=345
A correction is in order, this likely needs arch fields to be added. It should have been:

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345

-Steve
Post by Steve Grubb
That will get rid of all chmod calls by user account 345. Notice the
capital A, this places the rule at the beginning because the rule that
matches first wins. I would not make that a permanent rule, just a
workaround until it can be rebooted. But also note that it could
trigger other rules because it has a user's auid.
Post by LC Bruzenak
You cannot exclude an executable itself from the rule set by name.
The "exclude" option only applies to event types.
You could exclude it by type, except it is running as a generic
unconfined_t.
Yeah, as a daemon it should be something else. Unconfined is only from
a user session. Daemons get initrc_t when they are unknown.
-Steve
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit
Steve Grubb
2014-11-18 15:25:45 UTC
Permalink
Post by Tilden Doran D
Hi
auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A
exit,never -F arch=b64 -S chmod -F uid=345
we would require a permanent fix. If UID=345 is used, I believe that all
auditing functionality will not work for user ID=345,
Because the events shown are not translated, I can't tell what account 345 is.
I am assuming by its low number that its a system account. The rule above
drops all auditing of chmod syscalls for the 345 user account.
Post by Tilden Doran D
I mean if the userId(345) is logging in manually to the system and does some
operation that will also be exclude.
Again, I can onlt speculate what that account is. If its a daemon, then it
should have auid=-1 and the system works fine. Because the auid is 500, that
tells me that user 500 started it. Because uid!=auid, I assume its either
setuid or user 500 changed to root and then issued, "service ohasd restart".
Its one or the other.

If user 500 changed to root and restarted the daemon, then a reboot will fix
everything and a permanent solution is not needed. Or you can put the rule in
depending on how often this happens. But if this is for more than one system,
then I'd use the 345 user's name so that auditctl looks it up in case its
different on each machine. reserved accounts are generally under 200.
Post by Tilden Doran D
We want User inventions logs messages to be
captured but exclude the System generated logs.
The rules you gave have this in them:
-F auid>=500 -F auid!=4294967295

This is to exclude daemons because they have auid of -1 (unless restarted by
hand).
Post by Tilden Doran D
To be more detail.
Ohasd.bin process is started by the user( while starting the database
process) we want to captured this log.
The database is not started by the system on boot? Is this a system daemon or
a user session daemon?
Post by Tilden Doran D
But after that the ohasd.bin process
is running in background and it does lot of read write operations, we don't
want those logs.
Can you please let us know the way forward.
I am not familiar with that program, so I still need some answers to help you
figure out the right way to get rid of the events.

-Steve
Tilden Doran D
2014-11-19 05:38:24 UTC
Permalink
Hi Steve,



Yes, you are correct. We login as User 500 and switch user to oracle and issue the command.


The User 345 is oracle user. Which is used for oracle related activities in the system.



The command which we issue is srvctl stop/start database. We always install oracle and start manually for the first time.

As you mentioned, on reboot the system, it not generating too many logs. But the problem is, we cannot reboot the system every time, which only requires DB restart. Because application also be hosted in the same system.



The Srvctl command internally starts the ohasd.bin.

So can we avoid it, I mean do we have an option to exclude the ohasd.bin by using something like "-F exe!=ohasd.bin " or "-F path!= ...." . I tried both, it is not working.



Because "-F UID!=345" will restrict all the logs. Can we restrict the log which is generated by that particular process/application. ?





Thanks

Tilden







-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: Tuesday, November 18, 2014 8:56 PM
To: Tilden Doran D
Cc: linux-***@redhat.com
Subject: Re: Excluding few executable from audit.rules in redhat6.5
Post by Tilden Doran D
Hi
auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A
exit,never -F arch=b64 -S chmod -F uid=345
we would require a permanent fix. If UID=345 is used, I believe
that all auditing functionality will not work for user ID=345,
Because the events shown are not translated, I can't tell what account 345 is.

I am assuming by its low number that its a system account. The rule above drops all auditing of chmod syscalls for the 345 user account.
Post by Tilden Doran D
I mean if the userId(345) is logging in manually to the system and does some
operation that will also be exclude.
Again, I can onlt speculate what that account is. If its a daemon, then it

should have auid=-1 and the system works fine. Because the auid is 500, that

tells me that user 500 started it. Because uid!=auid, I assume its either

setuid or user 500 changed to root and then issued, "service ohasd restart".

Its one or the other.



If user 500 changed to root and restarted the daemon, then a reboot will fix

everything and a permanent solution is not needed. Or you can put the rule in

depending on how often this happens. But if this is for more than one system,

then I'd use the 345 user's name so that auditctl looks it up in case its

different on each machine. reserved accounts are generally under 200.
Post by Tilden Doran D
We want User inventions logs messages to be
captured but exclude the System generated logs.
The rules you gave have this in them:

-F auid>=500 -F auid!=4294967295



This is to exclude daemons because they have auid of -1 (unless restarted by

hand).
Post by Tilden Doran D
To be more detail.
Ohasd.bin process is started by the user( while starting the database
process) we want to captured this log.
The database is not started by the system on boot? Is this a system daemon or

a user session daemon?
Post by Tilden Doran D
But after that the ohasd.bin process
is running in background and it does lot of read write operations, we don't
want those logs.
Can you please let us know the way forward.
I am not familiar with that program, so I still need some answers to help you

figure out the right way to get rid of the events.



-Steve
Steve Grubb
2014-11-19 15:31:11 UTC
Permalink
Hello,
Post by Tilden Doran D
The User 345 is oracle user. Which is used for oracle related activities in the system.
The command which we issue is srvctl stop/start database. We always install
oracle and start manually for the first time.
As you mentioned, on reboot the system, it not generating too many logs. But
the problem is, we cannot reboot the system every time, which only
requires DB restart. Because application also be hosted in the same
system.
OK.
Post by Tilden Doran D
The Srvctl command internally starts the ohasd.bin.
So can we avoid it, I mean do we have an option to exclude the ohasd.bin by
using something like "-F exe!=ohasd.bin " or "-F path!= ...." . I tried
both, it is not working.
These are not possible. I have lobbied for audit by executable for a couple of
years. We are close to having it ready to go into the upstream kernel. But its
not ready and can't be used.

Normally one could exclude by SE Linux label, but since your original post
showed unconfined_t, then that means there is no policy because the daemon did
not transition out of unconfined_t.
Post by Tilden Doran D
Because "-F UID!=345" will restrict all the logs.
The rule that I gave you would filter only the chmod syscall caused by anything
with uid = 345. I think that is about the most reasonable choice you have
short of doing some selinux policy work so we have something pid specific to
match against.
Post by Tilden Doran D
Can we restrict the log which is generated by that particular
process/application. ?
You could add a rule using the pid, but next restart you'll have to change the
rule to the new pid. And probably by the time you can type that rule in, the
daemon has already done all the chmod that its going to do.

Maybe if the event are localized to a specific directory, you can do something
like:

auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 -F
dir=/opt/oracle_homes/oracle/
auditctl -A exit,never -F arch=b64 -S chmod -F uid=345 -F
dir=/opt/oracle_homes/oracle/


-Steve

Tilden Doran D
2014-11-18 10:10:25 UTC
Permalink
Hi,





Please find my response. Sorry for the delay, I am in different Time zone.





Well, what do you really want to do?



[Tilden] we want to implement audit Logging in Rhel 6.5. for the following events/actions.

Login, logout, switch user (su):

Rebooting the system, adding and deleting users, changing auditing and logging parameters, changing system clock:(all administrative actions),

Process start and stop

User executes a command





In general, I'd look at the original auditing rule to see if its scope can be narrowed. In this case, it appears that you are wanting all calls to chmod. Why?

[Tilden] My Audit.rules file for your reference. If possible please suggest me to narrowed down the audit rules for my requirement.







## First rule - delete all

-D



## Increase the buffers to survive stress events.

## Make this bigger for busy systems

-b 8192



## Set failure mode to panic

-f 2



## Things that could affect time

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change

-a always,exit -F arch=b64 -S clock_settime -F a0=0 -k time-change

-w /etc/localtime -p wa -k time-change



## Things that affect identity

-w /etc/group -p wa -k identity

-w /etc/passwd -p wa -k identity

-w /etc/gshadow -p wa -k identity

-w /etc/shadow -p wa -k identity

-w /etc/security/opasswd -p wa -k identity



## Things that could affect system locale

-a always,exit -F arch=b64 -S sethostname -S setdomainname -k system-locale

-w /etc/issue -p wa -k system-locale

-w /etc/issue.net -p wa -k system-locale

-w /etc/hosts -p wa -k system-locale

-w /etc/sysconfig/network -p wa -k system-locale



## Things that could affect MAC policy

-w /etc/selinux/ -p wa -k MAC-policy



## - Logon (unsuccessful and successful) and logout (successful)

-w /var/log/tallylog -p wa -k logins

-w /var/run/faillock/ -p wa -k logins

-w /var/log/lastlog -p wa -k logins



##- Discretionary access control permission modification (unsuccessful

## and successful use of chown/chmod)

-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod



##- Unauthorized access attempts to files (unsuccessful)

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access

-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access



##- Use of privileged commands (unsuccessful and successful)

## use find /bin -type f -perm -04000 2>/dev/null and put all those files in a rule like this

-a always,exit -F path=/bin/ping -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged



##- Export to media (successful)

-a always,exit -F arch=b64 -S mount -F auid>=500 -F auid!=4294967295 -k export



## sudo cannot record the action.

-w /etc/sudoers -p wa -k actions



## Optional - could be an attempt to bypass audit or simply legacy program

-a always,exit -F arch=b64 -S personality -F a0!=4294967295 -k bypass



Are you more concerned with failed calls to chmod, meaning a user is trying to change system files?

[Tilden] Yes, I am more concern with User level auditing. i.e. what and all actions performed by the user should be logged. we don't want the System process or any executable to generate logs.





Are system daemons calling chmod OK? Or do you really want everything?

[Tilden] We don't want the System process / daemons logs



Or do you want no events at all for that daemon no matter what the syscall?

[Tilden] Yes, we found 3 daemons which is causing the issue of generating lot of logs message, so we want to restrict those daemons from generating log messages, as we want only User level audit logs.





Thanks

Tilden





-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: Monday, November 17, 2014 9:01 PM
To: linux-***@redhat.com
Cc: Tilden Doran D
Subject: Re: Excluding few executable from audit.rules in redhat6.5
Post by Tilden Doran D
I am new to Redhat Audit logging.
Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and
SELinux is enabled.
We are getting lots of logs messages in /var/log/messages.
type=SYSCALL msg=audit(1416235337.083:2109222): arch=c000003e
syscall=90 success=yes exit=0 a0=7f52ae9f1a20 a1=3ff
a2=ffffffffffffff88
a3=fffffffffffffff0 items=1 ppid=1 pid=46859 auid=500 uid=345 gid=345
euid=345 suid=345 fsuid=345 egid=345 sgid=345 fsgid=345 tty=(none)
ses=28 comm="ohasd.bin" exe="/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod"
type=PATH msg=audit(1416235337.083:2109222): item=0
name="/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703"
inode=4718596 dev=fd:00 mode=041755 ouid=345 ogid=345 rdev=00:00
obj=unconfined_u:object_r:usr_t:s0 nametype=NORMAL
Later we found and removed message type "CWD", but still we are
getting lot of logs.
And also found that the below mentioned executable are creating the problem.
13351. 11/16/2014 18:11:34
/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500
1599360 13352. 11/16/2014 18:11:34
/opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle
(none) ? 500 1599354 13353. 11/16/2014 18:11:34
/opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500
1599361
Can you please help me in excluding the above mentioned Executable `s
in the audit. rules files .
Well, what do you really want to do? In general, I'd look at the original auditing rule to see if its scope can be narrowed. In this case, it appears that you are wanting all calls to chmod. Why? Are you more concerned with failed calls to chmod, meaning a user is trying to change system files? Are system daemons calling chmod OK? Or do you really want everything? Or do you want no events at all for that daemon no matter what the syscall?



The event you are showing is that app successfully making a directory world writable/readable. Its setting the sticky bit, so its "safe."



-Steve
Loading...