All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: [RFC] Virtual Key Fields
Date: Mon, 24 Mar 2008 09:42:14 -0400	[thread overview]
Message-ID: <1206366134.3192.14.camel@localhost.localdomain> (raw)
In-Reply-To: <200803240927.35073.sgrubb@redhat.com>

On Mon, 2008-03-24 at 09:27 -0400, Steve Grubb wrote:
> Hi,
> 
> Based on the discussion last week, I'd like to propose a technique of allowing 
> the appearance of multiple key fields without having to make changes in the 
> kernel. The kernel has one key field associated with each audit rule. It 
> doesn't look at the field's contents for anything. A patch will be submitted 
> for 2.6.26 kernel increasing the size of string the kernel will accept. The 
> kernel will still allocate the minimum memory needed to hold the string.

I really like it.  I think it is a good solution to the problem you were
trying to solve.


> Auditctl will also allow delete all rules matching a key. This will allow the 
> admin or a program to delete a set of rules related to just a particular key 
> and leave all other rules intact.

How does this work?  This is a completely new concept and it seems like
it should be a second patch after you have multiple keys in to start
with.

auditctl -a exit,always -w /tmp/file1 -k file1 -k shared-key
auditctl -a exit,always -w /tmp/file2 -k file2 -k shared-key

now if I say (and i'm just guessing your new syntax):

auditctl -d -k shared-key

what do I end up with?  no rules?  still 2 rules but without the -k
shared-key?

I really think this part of the proposal needs to be explained a whole
lot more before I buy into it.  I'm scared of trying to remove rules by
key and getting unanticipated results....

-Eric

  reply	other threads:[~2008-03-24 13:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 13:27 [RFC] Virtual Key Fields Steve Grubb
2008-03-24 13:42 ` Eric Paris [this message]
2008-03-24 13:52   ` Steve Grubb
2008-03-24 14:01     ` Eric Paris
2008-03-24 14:38 ` LC Bruzenak
2008-03-24 15:44 ` Klaus Heinrich Kiwi

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=1206366134.3192.14.camel@localhost.localdomain \
    --to=eparis@redhat.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.