RFE: log potential containers involved in namespace events #92
Assignees
Labels
Comments
|
Posted v3 kernel patchset upstream: |
|
V8 post: |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jan 3, 2020
This also adds support to qualify NETFILTER_PKT records. Audit events could happen in a network namespace outside of a task context due to packets received from the net that trigger an auditing rule prior to being associated with a running task. The network namespace could be in use by multiple containers by association to the tasks in that network namespace. We still want a way to attribute these events to any potential containers. Keep a list per network namespace to track these audit container identifiiers. Add/increment the audit container identifier on: - initial setting of the audit container identifier via /proc - clone/fork call that inherits an audit container identifier - unshare call that inherits an audit container identifier - setns call that inherits an audit container identifier Delete/decrement the audit container identifier on: - an inherited audit container identifier dropped when child set - process exit - unshare call that drops a net namespace - setns call that drops a net namespace Add audit container identifier auxiliary record(s) to NETFILTER_PKT event standalone records. Iterate through all potential audit container identifiers associated with a network namespace. Please see the github audit kernel issue for contid net support: linux-audit/audit-kernel#92 Please see the github audit testsuiite issue for the test case: linux-audit/audit-testsuite#64 Please see the github audit wiki for the feature overview: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jun 27, 2020
This also adds support to qualify NETFILTER_PKT records. Audit events could happen in a network namespace outside of a task context due to packets received from the net that trigger an auditing rule prior to being associated with a running task. The network namespace could be in use by multiple containers by association to the tasks in that network namespace. We still want a way to attribute these events to any potential containers. Keep a list per network namespace to track these audit container identifiiers. Add/increment the audit container identifier on: - initial setting of the audit container identifier via /proc - clone/fork call that inherits an audit container identifier - unshare call that inherits an audit container identifier - setns call that inherits an audit container identifier Delete/decrement the audit container identifier on: - an inherited audit container identifier dropped when child set - process exit - unshare call that drops a net namespace - setns call that drops a net namespace Add audit container identifier auxiliary record(s) to NETFILTER_PKT event standalone records. Iterate through all potential audit container identifiers associated with a network namespace. Please see the github audit kernel issue for contid net support: linux-audit/audit-kernel#92 Please see the github audit testsuiite issue for the test case: linux-audit/audit-testsuite#64 Please see the github audit wiki for the feature overview: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Dec 22, 2020
This also adds support to qualify NETFILTER_PKT records. Audit events could happen in a network namespace outside of a task context due to packets received from the net that trigger an auditing rule prior to being associated with a running task. The network namespace could be in use by multiple containers by association to the tasks in that network namespace. We still want a way to attribute these events to any potential containers. Keep a list per network namespace to track these audit container identifiiers. Add/increment the audit container identifier on: - initial setting of the audit container identifier via /proc - clone/fork call that inherits an audit container identifier - unshare call that inherits an audit container identifier - setns call that inherits an audit container identifier Delete/decrement the audit container identifier on: - an inherited audit container identifier dropped when child set - process exit - unshare call that drops a net namespace - setns call that drops a net namespace Add audit container identifier auxiliary record(s) to NETFILTER_PKT event standalone records. Iterate through all potential audit container identifiers associated with a network namespace. Sample event: type=NETFILTER_PKT msg=audit(2020-11-26 10:24:47.984:174549) : mark=0x15766399 saddr=127.0.0.1 daddr=127.0.0.1 proto=icmp record=1 type=CONTAINER_ID msg=audit(2020-11-26 10:24:47.984:174549) : record=1 contid=4112973747854606336,1916436506412318720 Please see the github audit kernel issue for contid net support: linux-audit/audit-kernel#92 Please see the github audit testsuiite issue for the test case: linux-audit/audit-testsuite#64 Please see the github audit wiki for the feature overview: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
|
2020-12-21 |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jan 12, 2021
This also adds support to qualify NETFILTER_PKT records. Audit events could happen in a network namespace outside of a task context due to packets received from the net that trigger an auditing rule prior to being associated with a running task. The network namespace could be in use by multiple containers by association to the tasks in that network namespace. We still want a way to attribute these events to any potential containers. Keep a list per network namespace to track these audit container identifiiers. Add/increment the audit container identifier on: - initial setting of the audit container identifier via /proc - clone/fork call that inherits an audit container identifier - unshare call that inherits an audit container identifier - setns call that inherits an audit container identifier Delete/decrement the audit container identifier on: - an inherited audit container identifier dropped when child set - process exit - unshare call that drops a net namespace - setns call that drops a net namespace Add audit container identifier auxiliary record(s) to NETFILTER_PKT event standalone records. Iterate through all potential audit container identifiers associated with a network namespace. Add the "record=" field to the A sample event: time->Thu Nov 26 10:24:47 2020 type=NETFILTER_PKT msg=audit(1606404287.984:174549): mark=0x15766399 saddr=127.0.0.1 daddr=127.0.0.1 proto=1 record=1 type=CONTAINER_ID msg=audit(1606404287.984:174549): record=1 contid=4112973747854606336,1916436506412318720 Please see the github audit kernel issue for contid net support: linux-audit/audit-kernel#92 Please see the github audit testsuiite issue for the test case: linux-audit/audit-testsuite#64 Please see the github audit wiki for the feature overview: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Log potential containers involved in namespace events.
Since network events could cause audit events that are not tied to a specific task, it is necessary to identify all potential containers that could have caused that event. Add a list of audit container identifiers that could use this network namespace and report them upon network events.
This depends on: #90
See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
The text was updated successfully, but these errors were encountered: