public inbox for linux-audit@redhat.com
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox