From: LC Bruzenak <lenny@magitekltd.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: exclude rule help
Date: Thu, 25 Jun 2009 20:22:05 -0500 [thread overview]
Message-ID: <1245979325.7681.24.camel@homeserver> (raw)
In-Reply-To: <200906252022.38719.sgrubb@redhat.com>
On Thu, 2009-06-25 at 20:22 -0400, Steve Grubb wrote:
> On Thursday 25 June 2009 06:01:08 pm LC Bruzenak wrote:
> > Anyone have a good idea of how to discard all these events? Ideally the
> > caller would send in a self-generated event such as "ryncing rick/src2/
> > to /temp-home" or similar. This is for a dedicated file backup
> > procedure.
> >
> > Obviously I do not want to discard all rsync events, just when launched
> > by our trusted program. Nor would I really want all that program's
> > events discarded since I want it to be able to submit proactive events
> > which summarize its behavior.
>
> With SE Linux, you can create different subject types based on how the
> application was started. Then you can exclude based on the type you assign to
> your subject whenever started by your trusted program.
>
> -Steve
Right, but wouldn't that preclude that same program from being able to
proactively submit its own records and also stop any inadvertent audit
events?
I guess I could:
1: start the first process with type1, let type1 audit what it plans to
do, then it could fork/exec/transition to type2.
2: the new process type2 could then run the rsync stuff. I could exclude
all the type2 records
3: the parent would wait for the child to complete and, based on the
exit code, audit success/failure as appropriate?
I guess this is the best way forward, however it scares me a little that
no events will then be logged from the process of that type2. If I
protect it I guess it's OK.
Thx!
LCB.
--
LC (Lenny) Bruzenak
lenny@magitekltd.com
prev parent reply other threads:[~2009-06-26 1:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 22:01 exclude rule help LC Bruzenak
2009-06-26 0:22 ` Steve Grubb
2009-06-26 1:22 ` LC Bruzenak [this message]
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=1245979325.7681.24.camel@homeserver \
--to=lenny@magitekltd.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.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