need for a trusted subtree was: Re: [rsyslog] Parsing the CEE payload before the trusted properties?

[David Lang]

cross-posting to the lumberjack mailing list where I raised the issue a few 
months ago

This is a report from the field that demonstrates the problem that I was trying 
to explain a few months ago on the lumberjack mailing list when I was advocating 
for there to be a 'trusted' subtree that an admin could configure to say that 
log input could never go there (instead being redirected to some other subtree)

Given that the trusted properties can be forged by root (and therefor sometimes 
are not really trusted) and other times you want to accept trusted properties as 
reported by a remote machine (where they could be forged by the sending 
machine), this is not something that can be baked directly into rsyslog.

Instead this needs to be something under the control of the admin. As with any 
controls, this needs to be made as simple as possible. Having to 
whitelist/blacklist a bunch of differnet fields[1] is just bad idea.

Instead, there should be some subtree that the admin can define on a 
case-by-case basis (I called it 'trusted') that all of these sorts of fields are 
in. That way the admin can just define that subtree and anything under it gets 
covered.

As I said in that discussion, there should be two subtrees that are defined with 
this command, the 'trusted' one that is not accepted from the source, and the 
'forged' one where any data that the source tries to send in either the 
'trusted' or 'forged' subtrees gets moved to.

so you would remap

trusted!exe -> forged!exe
forged!exe -> forged!forged!exe

David Lang

[1] the list of what fields need protection is almost certinly going to change 
over time and with different configurations.

Examples:

if namespaces are used, the values provided in the trusted properties may not 
really be the right ones (or at least they won't match what the application 
sees), so namespace information will probably be needed at some point

if the log is arriving from a remote system, fromhost-ip is a trusted 
property, cert information from a TLS handshake is a trusted property, etc

On Fri, 15 Mar 2013, Philippe Muller wrote:
> Hello rsyslog-users,
>
> I really like the idea of imuxsock's trusted properties and structured
> logging.
>
> However, when using both features lets users override the trusted
> properties.
> I guess It's because the JSON parsing takes place after the trusted
> properties parsing.
>
> Here is my configuration :
> $ModLoad imuxsock
> $SystemLogUsePIDFromSystem on
> $SystemLogSocketAnnotate on
> $SystemLogParseTrusted on
> module(load="mmjsonparse")
> *.* :mmjsonparse:
> if $parsesuccess == "FAIL" then set $!msg = $msg;
> template(name="cee" type="string" string="%$!all-json%\n")
> action(type="omusrmsg" users="*" template="cee")
>
> Results:
> logger foo
>
> => { "pid": 15385, "uid": 0, "gid": 0, "exe": "/usr/bin/logger", "cmd":
> "logger foo ", "msg": " foo" }
> logger '@cee: {"exe":"/bin/ls","cmd":"ls","pid":42,"gid":42,"uid":42}'
>
> => { "exe": "/bin/ls", "cmd": "ls", "pid": 42, "gid": 42, "uid": 42 }
>
> Is there a way to make mmjsonparse parses the CEE payload before parsing
> the trusted properties ? (making the trusted properties override user
> fields)
> Alternatively, is there a way to make mmjsonparse put user data in a
> subtree ?