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@redhat.com
Subject: Re: What is the bug
Date: Mon, 20 Jan 2014 15:25:57 -0500	[thread overview]
Message-ID: <1390249557.21885.15.camel@localhost> (raw)
In-Reply-To: <20140118085330.074d37c3@ivy-bridge>

What's the bugzilla?

On Sat, 2014-01-18 at 08:53 -0500, Steve Grubb wrote:
> Hello,
> 
> On Sat, 18 Jan 2014 20:02:37 +1100
> Burn Alting <burn@swtf.dyndns.org> wrote:
> > Consider the following raw audit event ...
> > 
> >         node=fedora20.swtf.dyndns.org type=CONFIG_CHANGE
> >         msg=audit(1390028319.573:20803): auid=4294967295
> > ses=4294967295 subj=system_u:system_r:auditctl_t:s0 op="remove rule"
> >         key="time-change" list=4 res=1
> > 
> > When the auparse library parses this event event, it does not
> > correctly parse the 'op' value and so both auparse_get_field_str() and
> > auparse_interpret_field() both return '"remove' rather than 'remove
> > rule'.
> 
> Correct. I have pointed this out for years and no one has wanted to fix
> it. The hex-encoding should only be used on fields that a user can
> influence, like file names. Since op= is always filled in by actual
> audit code - which is trusted, it should never _need_ encoding.
> Anywhere there is an op= and the field has blanks in it, it should be
> reformatted to have a dash between the words rather than a space. So,
> you would have remove-rule in your example. Untrusted string should
> never be used for this.
> 
> > Now, I seem to recollect an earlier e-mail that would suggest the bug
> > is in kernel/auditfilter.c:audit_receive_filter() as it calls
> > audit_log_rule_change() with the string "add rule" or "remove rule".
> > One assumes we need to perhaps either
> > a. replace the space with a hyphen in these arguments, or
> > b. in kernel/auditfilter.c:audit_log_rule_change() replace the call
> > 	audit_log_string(ab, action);
> > with
> > 	audit_log_untrustedstring(ab, action); 
> > 
> > If this is the case, then is there any appetite to have these bugs
> > fixed on the next update to the kernel audit code?
> 
> Yes please. I have been wanting this fixed for years. Grep all the auit
> code for this. I seem to recall problems in the ipsec and IMA code.
> 
> Thanks!
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

  reply	other threads:[~2014-01-20 20:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-18  9:02 What is the bug Burn Alting
2014-01-18 13:53 ` Steve Grubb
2014-01-20 20:25   ` Eric Paris [this message]
2014-01-20 21:05     ` Burn Alting
2014-01-20 21:08       ` Eric Paris

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=1390249557.21885.15.camel@localhost \
    --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.