public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: John Dennis <jdennis@redhat.com>
To: Joshua Roys <joshua.roys@gtri.gatech.edu>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Re: Backwards-compatible string encoding
Date: Fri, 27 Mar 2009 12:41:08 -0400	[thread overview]
Message-ID: <49CD01A4.5060408@redhat.com> (raw)
In-Reply-To: <49CCEE58.5010800@gtri.gatech.edu>

Joshua Roys wrote:
> Hello all,
>
> I have just run into the problem that many of you have: trying to 
> parse the audit logs.
> Based on things other people have proposed, how does this sound:
> - hex-encode strings (and do not quote) if:
> -- contains non-ASCII or non-printable characters
> - quote strings if:
> -- contains whitespace or '=' or '"' (in which case you have to output 
> something like '\"'
> -- entirely {hex,octal,base10} characters
>
> What do you all think?
Your suggestion requires a kernel change. NAK on any change which 
preserves hex-encoded strings, it was a bad idea to begin with, it 
remains a bad idea.

The reason why kernel audit output has not changed is fear of breaking 
current user space code. However it's been often stated the only code 
which is supposed to directly parse audit output is code from the audit 
package (e.g. auparse, etc.).

Strings should be formatted as strings which means enclosed in double 
quotes with standard C99 escaping.

As it stands now the audit libraries have hard coded lists of every 
field the kernel can emit in an audit message. The test for decoding hex 
strings is based on whether the field is known to be a string. Field 
values *never* currently begin with a quote. If the kernel audit code 
was modified to format strings such that they are always enclosed in 
quotes the following positive things would occur:

* No need for hard coded list of which fields are string values.

* As long as the audit libraries are used for parsing it's fully 
backwards compatible (because during parsing you first look for a quote, 
if it's there you know its a string value, otherwise fall back to the 
legacy logic).

* Strings are always human readable and it's obvious what is a string.

* C99 string encoding is trivial and extremely efficient so there is no 
burden on the kernel.

All in all a win/win situation.



-- 
John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

  reply	other threads:[~2009-03-27 16:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 15:18 Backwards-compatible string encoding Joshua Roys
2009-03-27 16:41 ` John Dennis [this message]
2009-04-09 19:55   ` Joshua Roys

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=49CD01A4.5060408@redhat.com \
    --to=jdennis@redhat.com \
    --cc=joshua.roys@gtri.gatech.edu \
    --cc=linux-audit@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