search

sudo-project / sudo

Utility to execute a command as another user
https://www.sudo.ws
Other
1.14k stars 209 forks source link

Parsing issue: log_format=json to local file, only multiline json, but single line is the way to go. #357

Closed SirStephanikus closed 4 months ago

SirStephanikus commented 5 months ago

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.

millert commented 5 months ago

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.

SirStephanikus commented 5 months ago

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.

millert commented 4 months ago

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.

SirStephanikus commented 4 months ago

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.

millert commented 4 months ago

@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 commented 4 months ago

@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

SirStephanikus commented 4 months ago

Perhaps you send an example and I test if a SIEM parser can parse it?

millert commented 4 months ago

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.