On Tue, 9 Oct 2012, Rainer Gerhards wrote:
>> Then may be the fields that are generated by the interface
should
> have a
>> prefix that by convention is not used for other fields. For example
>> instead of: pid - resolved_pid or something like. And IMO attempt to
>> explicitly overwrite such field in the call should return an error
> right
>> away.
>
> exactly. If we support hierarchical structures, we can use a single
> tag,
> if we make everything flat, we can reserve a prefix (ideally, a prefix
> that translates to a subtree name so that people who want it flat can
> treat it as if it's flat, people who want hierarchical can treat it as
> a
> subtree)
>
> I would actually reserve two prefixes/subtree names
>
> The first for the tags that are generated by the logging infrastructure
>
> The second for a place to relocate any tags that are passed to us in a
> reserved space.
>
> for the sake of argument, call these 'trusted.' and 'forged.' If
> someone
> submits something with trusted.uid, move it to forged.trusted.uid. If
> someone submits something with forged.uid move it to forged.forged.uid.
>
>> If the prefix is unique there is a very low chance that the resolved
>> fields would be overwritten unintentionally.
>
> exactly.
>
> Now, from the discussion a couple of weeks ago, people have a real hard
> time with 'trusted' (arguments crop up about how much you can really
> trust
> it), so we need to pick something else.
>
> we could do lumberjack. for trusted and beaver. for forged :-) This is
> a
> bit long, someone with more creativity can pick a couple of names.
I strongly like the prefix idea. It makes it easy to protect these
fields.
HOWEVER, this raises another question. How far will we go protecting
them? This issue was also raised in the last discussion, but no solution
was found.
The problem is with relaying. Let's say we have
App-A->local log socket-B->syslogd-C->remote syslogd
Where in C we have a network transfer. I assume that the syslogd will
take "trusted" data from the OS at point B and at the same time can
prohibit forged data from the app. HOWEVER, what happens at the remote
syslogd after the network transfer in C? Do we permit it to trust the
data contained in the network package - or what do we need to do?
IMHO, the solution is to accept that data, but recommend that the
syslogd (any logger meant) implementation will use different policies,
e.g. trusted data may not be accepted via regular transfer, but via
TLS-protected transfer with mutual authentication (or at least sender
authentication).
I think that is going to be up to the sysadmin to determine how trusted
the data is.
what you are suggesting is a reasonable default.
David Lang