What is the bug
Steve Grubb
sgrubb at redhat.com
Sat Jan 18 13:53:30 UTC 2014
Hello,
On Sat, 18 Jan 2014 20:02:37 +1100
Burn Alting <burn at 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
More information about the Linux-audit
mailing list