Re: [logs] Syslog payload format

krhat_private

On Fri, 20 Dec 2002 14:33:59 +0100, "Rainer Gerhards" wrote:
> > (the payload) in your log.  We need to account for the=20
> > possibility that log data will have \0's liberally inserted.
> >=20
> > So we want an interface more like:
> >=20
> > event_new(&evt);
> > event_tag(&evt, "TAG", data, data_length);
> > event_send(&evt);
> > event_del(&evt);
> >=20
> 
> Well... Basically, I think binary data is helpful. BUT: wouldn't that
> break all existing parsing solutions? Sure, we could re-write them but I
> have at least the feeling that by not allowing binary data we would
> loose a little but gain much more...

Or would it really change anything at all?  I'm sure that you can insert nulls
in all sorts of ways already.

But in a sense that's the wrong discussion.  The interface to the programmer
should be independent of how the log data is actually stored.  No programmer
should have to do any additional work to log potentially harmful
characters; that's a needless inconvienience he should be spared.

That leaves the question of how the logged data should actually be stored.
As I said before, I don't think it changes the situation any to declare syslog
data to be binary.  I think it's the best solution for automated processing;
it requires a small amount of additional work, at least if you're working in
C, but you end up doing it correctly instead of being fooled by nulls.  But
it can be very inconvienient, and even dangerous, if you're just browsing
through your logs on a terminal: a devoted attacker can include control
characters to mess up your terminal or even, potentially, buffer overflow
your text pager.

We're all paranoid, I think; so, safety first: we need a binary API and a
safe printable ASCII storage format.  I liked someone's earlier suggestion
of percent encoding, mostly because it's fairly legible.  Other ideas?

-- 
Kyle R. Hofmann <krhat_private>
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis