All of lore.kernel.org
 help / color / mirror / Atom feed
From: LC Bruzenak <lenny@magitekltd.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: user audits
Date: Fri, 03 Dec 2010 10:12:25 -0600	[thread overview]
Message-ID: <1291392745.2184.38.camel@lcb> (raw)
In-Reply-To: <201012031054.35569.sgrubb@redhat.com>

On Fri, 2010-12-03 at 10:54 -0500, Steve Grubb wrote:
> On Friday, December 03, 2010 10:40:37 am LC Bruzenak wrote:
> > Would there be any issue with adding a couple new trusted_application
> > event types? Would any kernel mods be needed to support this?
> 
> Are these events originating in user space or the kernel? I might be convinced to set 
> aside the block of IDs from 2600 - 2699 for local use if a suitable framework were 
> written. This would mean that there is some config file that holds the local mapping of 
> event IDs to text and ausearch/report/parse will need to be patched to understand 
> local definitions.

Great!
>From user space only. Analogous to signal handling of SIGUSR1, SIGUSR2
where the framework supports the user-implemented pieces. 

I was thinking ausearch/auparse would treat all the TRUSTED_APPs the
same...since they (currently) fails to parse these correctly anyway
IMHO. :)

Everything else could treat the additional user types exactly as they do
the TRUSTED_APP event now. When I dig through the events on the back end
I would be able to act differently on the ones I know I've put in place
on the originating end.

> 
> Would you be interested in this approach?

Absolutely! 
I will be starting work on some stuff which could utilize this after the
holidays. If it gets into RHEL6 I would be thrilled!

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

  reply	other threads:[~2010-12-03 16:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 15:40 user audits LC Bruzenak
2010-12-03 15:54 ` Steve Grubb
2010-12-03 16:12   ` LC Bruzenak [this message]
2010-12-03 16:25     ` Steve Grubb

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=1291392745.2184.38.camel@lcb \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.