Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit: Implement support for fork/vfork/clone/execveat #5701

Conversation

alessandrogario
Copy link
Member

@alessandrogario alessandrogario commented Aug 12, 2019

This fixes issue #5691

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 12, 2019

CLA Check
The committers are authorized under a signed CLA.

@alessandrogario alessandrogario added events Related to osquery's evented tables or eventing subsystem Linux process auditing labels Aug 12, 2019
@alessandrogario alessandrogario force-pushed the alessandro/feature/fork-process-events branch 2 times, most recently from 0352539 to ce6a318 Compare August 13, 2019 21:24
@theopolis
Copy link
Member

Wow, cool!

@alessandrogario alessandrogario marked this pull request as ready for review August 14, 2019 00:32
@loqpa
Copy link

loqpa commented Aug 16, 2019

What do you think about filling mode column with info from file table in case there are no PATH records?

}

} else if (FLAGS_audit_allow_fork_process_events) {
LOG(WARNING) << "--audit_allow_fork_process_events is ignored without "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should investigate if this dependency can be expressed using the gflags APIs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be compared to enabling --audit_allow_config without also having the command line flag that enables Audit.

If we want to conform to the rest of the code, we can just remove the warning log. Otherwise, we could implement a flag validator and make sure that both flags are active.

Which one would you prefer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, my comment was too general and not helpful. You are right in that we should address/explore gflags more completely later.

Always your call!


row["cmdline"] += DecodeAuditPathValues(arg.second);
if (row["cmdline"].size() > 0) {
row["cmdline"] += " ";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also += ' '

return Status::failure("Malformed AUDIT_EXECVE event");
}

row["cmdline"] = "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the same as .clear().

return Status::failure("Malformed AUDIT_CWD event");
}

CopyFieldFromMap(row, cwd_event_record->fields, "cwd", "");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see common calls with "" and "0" as the third argument. Is it worth making this API more explicit with an overload + fall through?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those arguments are the default value to adopt in case the specified field is missing in the field map, and varies depending on the context. How would you change this?

theopolis
theopolis previously approved these changes Aug 19, 2019
Copy link
Member

@theopolis theopolis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at the inline notes I left. Overall this looks good, GetProcessIDs looks complex but also well tested.

theopolis
theopolis previously approved these changes Aug 21, 2019
@alessandrogario
Copy link
Member Author

What do you think about filling mode column with info from file table in case there are no PATH records?

Are you referring to something similar to this? https://github.com/osquery/osquery/pull/5701/files#diff-ba6fdbb94c1ce5b8f9a3950608fbe86fR59

In general, I think we should avoid having too many SELECTs on other tables inside the code (which also makes testing harder). We could maybe achieve the same using a JOIN in the query?

@loqpa
Copy link

loqpa commented Aug 22, 2019

What do you think about filling mode column with info from file table in case there are no PATH records?

Are you referring to something similar to this? https://github.com/osquery/osquery/pull/5701/files#diff-ba6fdbb94c1ce5b8f9a3950608fbe86fR59

In general, I think we should avoid having too many SELECTs on other tables inside the code (which also makes testing harder). We could maybe achieve the same using a JOIN in the query?

I am not entirely sure how selectAllFrom works, but i think something like
if (row["mode"]=="") row["mode"] = qd.front().at("mode")
at line 67 should not introduce any new SELECTs.

If i am wrong - it is definitely achievable with joins, i already use almost the same logic while joining processes table which does not have mode column.

However i understand that in my case mode column would be a little inconsistent (4 digits records from file vs 7 digits from PATH). This is the main reason behind my question.

@alessandrogario
Copy link
Member Author

What do you think about filling mode column with info from file table in case there are no PATH records?

Are you referring to something similar to this? https://github.com/osquery/osquery/pull/5701/files#diff-ba6fdbb94c1ce5b8f9a3950608fbe86fR59
In general, I think we should avoid having too many SELECTs on other tables inside the code (which also makes testing harder). We could maybe achieve the same using a JOIN in the query?

I am not entirely sure how selectAllFrom works, but i think something like
if (row["mode"]=="") row["mode"] = qd.front().at("mode")
at line 67 should not introduce any new SELECTs.

If i am wrong - it is definitely achievable with joins, i already use almost the same logic while joining processes table which does not have mode column.

I see what you mean now! Thanks for the explanation 👍

@alessandrogario alessandrogario changed the base branch from master to thirdparty-submodules August 22, 2019 12:20
@alessandrogario alessandrogario changed the base branch from thirdparty-submodules to master August 22, 2019 12:20
@alessandrogario
Copy link
Member Author

I know it may seem weird but GitHub had no idea what was happening in the PR until we forced it to update by changing the base branch.... 🤔

All seems good now

@alessandrogario alessandrogario merged commit 444b2cc into osquery:master Aug 23, 2019
@alessandrogario alessandrogario deleted the alessandro/feature/fork-process-events branch August 23, 2019 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
events Related to osquery's evented tables or eventing subsystem Linux process auditing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants