[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-audit
Subject:    Re: [RFC] [PATCH]
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2006-02-17 18:27:53
Message-ID: 1140200873.29938.16.camel () moss-spartans ! epoch ! ncsc ! mil
[Download RAW message or body]

On Fri, 2006-02-17 at 11:49 -0500, Amy Griffis wrote:
> I don't think it can be that simple.  Historically, audit filter
> operations have been read-only.  Rcu is used because waiting on any
> other kind of lock would be a bottleneck to the syscall path.
> 
> You are introducing a write operation to part of the filterlist while
> we are only holding read locks (rcu_read_lock() in auditsc.c and
> POLICY_RDLOCK here).  This could conflict with other readers and
> writers of this data.
> 
> One option is to introduce a field-specific lock.  When audit rules
> are configured such that the field applies to only a few syscalls,
> then syscall processing isn't affected very much.  However, we can't
> dictate that audit rules are written in this way, so I doubt we can
> make a case for this.
> 
> The other option requires audit to be aware of the update so it can
> make a new copy of the rule and do a list_replace_rcu().  This
> shouldn't happen during filtering though.  
> 
> I'm of the opinion that syscall filtering should remain read-only.
> Anything else isn't going to scale well.

Yes, thanks for pointing this out.  Which means that audit needs to
register a callback for policy reloads and re-process the audit filters
upon the reload operation itself, not at filter check time.

-- 
Stephen Smalley
National Security Agency

[prev in list] [next in list] [prev in thread] [next in thread]