Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd a new audit-based table to collect SELinux events #4224
Conversation
|
@alessandrogario has updated the pull request. View: changes |
|
ok to test |
| description("Track SELinux events.") | ||
| schema([ | ||
| Column("type", TEXT, "Event type"), | ||
| Column("msg", TEXT, "Message"), |
theopolis
May 14, 2018
Member
I will get back to a more-complete review later, but I don't want to forget things. I would recommend message as that is already used in asl and user_events. The msg shorthand is not used anywhere.
I will get back to a more-complete review later, but I don't want to forget things. I would recommend message as that is already used in asl and user_events. The msg shorthand is not used anywhere.
alessandrogario
May 14, 2018
•
Author
Contributor
The field names are trying to match what is shown in the default (i.e. without osquery) auditd log so that (hopefully) the syntax is similar. I can rename it to "message" if you prefer!
EDIT:
This also applies to the "type" field.
Reference I used for the syntax: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-understanding_audit_log_files
The field names are trying to match what is shown in the default (i.e. without osquery) auditd log so that (hopefully) the syntax is similar. I can rename it to "message" if you prefer!
EDIT:
This also applies to the "type" field.
Reference I used for the syntax: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-understanding_audit_log_files
theopolis
May 17, 2018
Member
Ah, my vote is still for message please :)
Ah, my vote is still for message please :)
| table_name("selinux_events") | ||
| description("Track SELinux events.") | ||
| schema([ | ||
| Column("type", TEXT, "Event type"), |
theopolis
May 14, 2018
Member
note, in user_events this is an Integer.
note, in user_events this is an Integer.
alessandrogario
May 17, 2018
Author
Contributor
I have renamed msg to message, but for the type column I'm using text labels; would you like me to change this? I could move the label to another column (like type_name) and change type back to integer
I have renamed msg to message, but for the type column I'm using text labels; would you like me to change this? I could move the label to another column (like type_name) and change type back to integer
|
@alessandrogario has updated the pull request. |
| // clang-format off | ||
| // This map must contain exactly the same elements that | ||
| // SELinuxEventSubscriber::GetEventSet() returns! | ||
| const std::map<int, std::string> record_type_to_label = { |
theopolis
May 17, 2018
Member
This should be named kSELinuxRecordLabels or something similar.
This should be named kSELinuxRecordLabels or something similar.
| // - USER_MAC_POLICY_LOAD | ||
| // - USER_ROLE_CHANGE | ||
| // - USER_LABEL_EXPORT | ||
| static const std::set<int> selinux_event_list = { |
theopolis
May 17, 2018
Member
This is weird, too many statics. I would define this const set somewhere outside of the class. Similar to the record-label lookup.
This is weird, too many statics. I would define this const set somewhere outside of the class. Similar to the record-label lookup.
theopolis
May 17, 2018
Member
If there's a requirement to have each of these in the label map above, please include a test!
If there's a requirement to have each of these in the label map above, please include a test!
| description("Track SELinux events.") | ||
| schema([ | ||
| Column("type", TEXT, "Event type"), | ||
| Column("msg", TEXT, "Message"), |
theopolis
May 17, 2018
Member
Ah, my vote is still for message please :)
Ah, my vote is still for message please :)
|
@alessandrogario has updated the pull request. View: changes |
|
@alessandrogario has updated the pull request. |
|
Does this change include any performance impact to machines configured to do process and socket auditing? |
Although there's already a windows-only 3.4[1], the latest release for Unix systems is 3.3.2[2] with the following changes: * SELinux event recording[3] * SMART drive information[4] * ELF parsing to monitor compiler-level protections for binaries[5] The diff became rather big in the end due to the following changes: * The SMART information feature uses a custom fork of smartmontools to retrieve SMART data programatically[6]. * Replaced the old, bloated `misc.patch` by a simpler patch that only fixes two (actual) issues in the CMake build, unnecessary link targets and an invalid compiler flag. * I tried to clean the derivation's code up a little bit by simplifying the `preConfigure` hook and adding only one build-input per line (that makes merging of several changes to the derivation easier as well). [1] https://github.com/facebook/osquery/releases/tag/3.4.0 [2] https://github.com/facebook/osquery/releases/tag/3.3.2 [3] osquery/osquery#4224 [4] osquery/osquery#4133 [5] osquery/osquery#4708 [6] https://github.com/allanliu/smartmontools
Although there's already a windows-only 3.4[1], the latest release for Unix systems is 3.3.2[2] with the following changes: * SELinux event recording[3] * SMART drive information[4] * ELF parsing to monitor compiler-level protections for binaries[5] The diff became rather big in the end due to the following changes: * The SMART information feature uses a custom fork of smartmontools to retrieve SMART data programatically[6]. * Replaced the old, bloated `misc.patch` by a simpler patch that only fixes two (actual) issues in the CMake build, unnecessary link targets and an invalid compiler flag. * I tried to clean the derivation's code up a little bit by simplifying the `preConfigure` hook and adding only one build-input per line (that makes merging of several changes to the derivation easier as well). [1] https://github.com/facebook/osquery/releases/tag/3.4.0 [2] https://github.com/facebook/osquery/releases/tag/3.3.2 [3] osquery/osquery#4224 [4] osquery/osquery#4133 [5] osquery/osquery#4708 [6] https://github.com/allanliu/smartmontools
Although there's already a windows-only 3.4[1], the latest release for Unix systems is 3.3.2[2] with the following changes: * SELinux event recording[3] * SMART drive information[4] * ELF parsing to monitor compiler-level protections for binaries[5] The diff became rather big in the end due to the following changes: * The SMART information feature uses a custom fork of smartmontools to retrieve SMART data programatically[6]. * Replaced the old, bloated `misc.patch` by a simpler patch that only fixes two (actual) issues in the CMake build, unnecessary link targets and an invalid compiler flag. * I tried to clean the derivation's code up a little bit by simplifying the `preConfigure` hook and adding only one build-input per line (that makes merging of several changes to the derivation easier as well). [1] https://github.com/facebook/osquery/releases/tag/3.4.0 [2] https://github.com/facebook/osquery/releases/tag/3.3.2 [3] osquery/osquery#4224 [4] osquery/osquery#4133 [5] osquery/osquery#4708 [6] https://github.com/allanliu/smartmontools
This PR adds a new table called
selinux_eventsthat collects SELinux events using audit.Here's how it looks:
Possible values for the type column:
How it works
The SELinux subsystem does not conform to the audit record syntax, meaning that the messages we receive can't be correctly parsed. To work around this issue, the data is stored and shown in raw format, similar to how it appears in the usual SELinux log files.
How to test it
As with the other audit-based tables, it is mandatory to enable audit, events and the required audit tables: