Linda Knippers wrote:
Steve Grubb wrote:
In a binary representation, you would have a version number to
describe what structure to cast the pointer to. If you have new log
with old user space, it won't parse because it won't have the
template to cast with.
Is that any different from not being able to parse something the tools
don't know about?
It's useful to distinguish between two entirely different concepts which
are at play here, but unfortunately get confused and intermingled,
parsing and interpretation. A well designed protocol is always parsable
by any version of the parser and any version of the input stream. This
can be achieved because the protocol stream is well defined and any
unknown protocol elements can be "stepped over". Once parsed any given
protocol element is subject to interpretation, this is version specific.
For example in the v2 protocol a "security identifier" (i.e. sid) might
have been added, only a v2 tool could properly interpret the "sid" but a
v1 parser could still parse the v2 stream (in fact a v1 parser should
also be able to know the type of the unknown "sid", e.g. integer,
string, etc.)
Extensible protocol design is a mature (and relatively simple) computer
science discipline. The paradigm most likely to be familiar to people is
ASN.1, but there are a host of other equally valid approaches, both
binary and text based (I am not advocating for any given protocol design
paradigm, but I do advocate we adopt one).
The reality is the audit stream is a protocol. The problem is the audit
stream never had the principles of protocol design applied to it. We've
tried to compensate for the lack of protocol rigorousness in the data
stream by building a parser with special case exceptions and heuristics
which is inherently unsustainable. If instead the audit data stream
followed the rigours of a network protocol most of these issues would
simply vanish.
--
John Dennis <[EMAIL PROTECTED]>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
