Parsing issue: log_format=json to local file, only multiline json, but single line is the way to go. · Issue #357 · sudo-project/sudo (original) (raw)
Configuring sudo with log_format=json and storing it to a local file, results in a multiline JSON which can not be directly parsed by a SIEM. Various workarounds must be made.
However, it would be way easier if sudo would store its JSON content in single line instead of multiline.
The file-based json log was intended to be both human and machine readable, but perhaps that isn't the most useful default. I'll look into adding an option to log in single-line form, one record per line with no enclosing object which I believe is what you are after. BTW, if you log via syslog, the json records will be single-line.
The file-based json log was intended to be both human and machine readable, but perhaps that isn't the most useful default. I'll look into adding an option to log in single-line form, one record per line with no enclosing object which I believe is what you are after. BTW, if you log via syslog, the json records will be single-line.
With syslog I know, but a single line JSON with no syslog at all involved is IMHO the modern way.
Regarding the human friendly output:cat sudo_as_singleline_json.json | jq
will give a beautiful output, imho there is no need to implement a multiline variant.
Defaulting to a single line per entry is simple enough. However, the json-format log file currently consists of a single object that contains all the log entries. What would be most useful for passing to a SIEM? A separate object per line or the existing practice of a single object where each line represents an entry? I'm guessing that one object per line would be easier to deal with but would like confirmation of that.
Defaulting to a single line per entry is simple enough. However, the json-format log file currently consists of a single object that contains all the log entries. What would be most useful for passing to a SIEM? A separate object per line or the existing practice of a single object where each line represents an entry? I'm guessing that one object per line would be easier to deal with but would like confirmation of that.
A SIEM needs the whole JSON object ... everything, all the nested goodies etc. even if it means to 1000+ nested items. But it has to be a single line, not multiline.
I don't know any SIEM that can parse Multiline JSON.
@SirStephanikus I'm just trying to understand how you want to use this. Do you want the entire file to be a single line or multiple lines, each with independent JSON objects? I'm hoping you mean the latter.
@SirStephanikus I'm just trying to understand how you want to use this. Do you want the entire file to be a single line or multiple lines, each with independent JSON objects? I'm hoping you mean the latter.
A single logfile that can contain 1000+ single line JSONs.
I.E.
LINE 1: Ultra-Mega complex JSON Object with tons of nested stuff -- related to a single event and one Ulta-Mega complex single line entry.
LINE 2: Same as LINE 1, but another event
Perhaps you send an example and I test if a SIEM parser can parse it?
millert added a commit that referenced this issue
The "json_compact" log type logs one event per line in compact/minified JSON format. GitHub issue #357.
Rather than change the behavior of the default json logging, which would harm existing users, I added a "json_compact" format which logs one event per line. Each line is a standalone JSON objection, whereas the "json" logging format uses a single object for the entire file. I may deprecate the multi-line JSON format in the future but I'd like to avoid breaking people's existing configs.
millert added a commit that referenced this issue
In a future version, "json" will be an alias for "json_compact" instead. GitHub issue #357.