From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: What is the bug Date: Sat, 18 Jan 2014 08:53:30 -0500 Message-ID: <20140118085330.074d37c3@ivy-bridge> References: <1390035757.2901.39.camel@swtf.swtf.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1390035757.2901.39.camel@swtf.swtf.dyndns.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: burn@swtf.dyndns.org Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, On Sat, 18 Jan 2014 20:02:37 +1100 Burn Alting 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