From: Steve Grubb <sgrubb@redhat.com>
To: Tilden Doran D <tilden.doran.d@ericsson.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Re: Excluding few executable from audit.rules in redhat6.5
Date: Wed, 19 Nov 2014 10:31:11 -0500 [thread overview]
Message-ID: <6688953.p0Ds4QAG8f@x2> (raw)
In-Reply-To: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C78A@eusaamb103.ericsson.se>
Hello,
On Wednesday, November 19, 2014 05:38:24 AM Tilden Doran D wrote:
> 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.
> 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.
> 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.
> 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
next prev parent reply other threads:[~2014-11-19 15:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 15:02 Excluding few executable from audit.rules in redhat6.5 Tilden Doran D
2014-11-17 15:30 ` Steve Grubb
2014-11-17 16:14 ` LC Bruzenak
2014-11-17 16:42 ` Steve Grubb
2014-11-17 17:09 ` Steve Grubb
2014-11-18 10:22 ` Tilden Doran D
2014-11-18 15:25 ` Steve Grubb
2014-11-19 5:38 ` Tilden Doran D
2014-11-19 15:31 ` Steve Grubb [this message]
2014-11-18 10:10 ` Tilden Doran D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6688953.p0Ds4QAG8f@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=tilden.doran.d@ericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).