| Message ID | cover.1554732921.git.rgb@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | audit: implement container identifier | expand |
On 2019-04-08 23:39, Richard Guy Briggs wrote: > Implement kernel audit container identifier. Here's a first revision of the conversion of my manual test script from bash to automated perl in the audit-testsuite: https://github.com/linux-audit/audit-testsuite/pull/83 It revealed some bugs/limitations in userspace code. One is an omission in my userspace code support for these features that treat the contid field in the CONATAINER_ID auxiliary record to the NETFILTER_PKT record as a comma separated list (I already have a patch). Another is the inability to search on contid in CONTAINER_ID fields (complicated by the previous issue). A third (already noted in ghau86) is the failure to group records of the same event if the record number is in the 1000 block. Another is pondering the addition of an old-contid search option. Despite these limitations, the test script works. > This patchset is a fifth based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > The first patch was the last patch from ghak81 that was absorbed into > this patchset since its primary justification is the rest of this > patchset. > > The second patch implements the proc fs write to set the audit container > identifier of a process, emitting an AUDIT_CONTAINER_OP record to > announce the registration of that audit container identifier on that > process. This patch requires userspace support for record acceptance > and proper type display. > > The third implements reading the audit container identifier from the > proc filesystem for debugging. This patch wasn't planned for upstream > inclusion but is starting to become more likely. > > The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit > container identifier is associated with an event. This patch requires > userspace support for proper type display. > > The 5th adds audit daemon signalling provenance through audit_sig_info2. > > The 6th creates a local audit context to be able to bind a standalone > record with a locally created auxiliary record. > > The 7th patch adds audit container identifier records to the user > standalone records. > > The 8th adds audit container identifier filtering to the exit, > exclude and user lists. This patch adds the AUDIT_CONTID field and > requires auditctl userspace support for the --contid option. > > The 9th adds network namespace audit container identifier labelling > based on member tasks' audit container identifier labels. > > The 10th adds audit container identifier support to standalone netfilter > records that don't have a task context and lists each container to which > that net namespace belongs. > > Example: Set an audit container identifier of 123456 to the "sleep" task: > > sleep 2& > child=$! > echo 123456 > /proc/$child/audit_containerid; echo $? > ausearch -ts recent -m container_op > echo child:$child contid:$( cat /proc/$child/audit_containerid) > > This should produce a record such as: > > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes > > > Example: Set a filter on an audit container identifier 123459 on /tmp/tmpcontainerid: > > contid=123459 > key=tmpcontainerid > auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); close(\$tmpfile);" & > child=$! > echo $contid > /proc/$child/audit_containerid > sleep 2 > ausearch -i -ts recent -k $key > auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > rm -f /tmp/$key > > This should produce an event such as: > > type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459 > type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root > type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffffffffffff9c a1=0x5621f2b81900 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid > > Example: Test multiple containers on one netns: > > sleep 5 & > child1=$! > containerid1=123451 > echo $containerid1 > /proc/$child1/audit_containerid > sleep 5 & > child2=$! > containerid2=123452 > echo $containerid2 > /proc/$child2/audit_containerid > iptables -I INPUT -i lo -p icmp --icmp-type echo-request -j AUDIT --type accept > iptables -I INPUT -t mangle -i lo -p icmp --icmp-type echo-request -j MARK --set-mark 0x12345555 > sleep 1; > bash -c "ping -q -c 1 127.0.0.1 >/dev/null 2>&1" > sleep 1; > ausearch -i -m NETFILTER_PKT -ts boot|grep mark=0x12345555 > ausearch -i -m NETFILTER_PKT -ts boot|grep contid=|grep $containerid1|grep $containerid2 > > This should produce an event such as: > > type=NETFILTER_PKT msg=audit(03/15/2019 14:16:13.369:244) : mark=0x12345555 saddr=127.0.0.1 daddr=127.0.0.1 proto=icmp > type=CONTAINER_ID msg=audit(03/15/2019 14:16:13.369:244) : contid=123452,123451 > > > Includes the last patch of https://github.com/linux-audit/audit-kernel/issues/81 > Please see the github audit kernel issue for the main feature: > https://github.com/linux-audit/audit-kernel/issues/90 > and the kernel filter code: > https://github.com/linux-audit/audit-kernel/issues/91 > and the network support: > https://github.com/linux-audit/audit-kernel/issues/92 > Please see the github audit userspace issue for supporting record types: > https://github.com/linux-audit/audit-userspace/issues/51 > and filter code: > https://github.com/linux-audit/audit-userspace/issues/40 > Please see the github audit testsuiite issue for the test case: > https://github.com/linux-audit/audit-testsuite/issues/64 > Please see the github audit wiki for the feature overview: > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID > > > Changelog: > > v6 > - change TMPBUFLEN from 11 to 21 to cover the decimal value of contid > u64 (nhorman) > - fix bug overwriting ctx in struct audit_sig_info, move cid above > ctx[0] (nhorman) > - fix bug skipping remaining fields and not advancing bufp when copying > out contid in audit_krule_to_data (omosnacec) > - add acks, tidy commit descriptions, other formatting fixes (checkpatch > wrong on audit_log_lost) > - cast ull for u64 prints > - target_cid tracking was moved from the ptrace/signal patch to > container_op > - target ptrace and signal records were moved from the ptrace/signal > patch to container_id > - auditd signaller tracking was moved to a new AUDIT_SIGNAL_INFO2 > request and record > - ditch unnecessary list_empty() checks > - check for null net and aunet in audit_netns_contid_add() > - swap CONTAINER_OP contid/old-contid order to ease parsing > > v5 > - address loginuid and sessionid syscall scope in ghak104 > - address audit_context in CONFIG_AUDIT vs CONFIG_AUDITSYSCALL in ghak105 > - remove tty patch, addressed in ghak106 > - rebase on audit/next v5.0-rc1 > w/ghak59/ghak104/ghak103/ghak100/ghak107/ghak105/ghak106/ghak105sup > - update CONTAINER_ID to CONTAINER_OP in patch description > - move audit_context in audit_task_info to CONFIG_AUDITSYSCALL > - move audit_alloc() and audit_free() out of CONFIG_AUDITSYSCALL and into > CONFIG_AUDIT and create audit_{alloc,free}_syscall > - use plain kmem_cache_alloc() rather than kmem_cache_zalloc() in audit_alloc() > - fix audit_get_contid() declaration type error > - move audit_set_contid() from auditsc.c to audit.c > - audit_log_contid() returns void > - audit_log_contid() handed contid rather than tsk > - switch from AUDIT_CONTAINER to AUDIT_CONTAINER_ID for aux record > - move audit_log_contid(tsk/contid) & audit_contid_set(tsk)/audit_contid_valid(contid) > - switch from tsk to current > - audit_alloc_local() calls audit_log_lost() on failure to allocate a context > - add AUDIT_USER* non-syscall contid record > - cosmetic cleanup double parens, goto out on err > - ditch audit_get_ns_contid_list_lock(), fix aunet lock race > - switch from all-cpu read spinlock to rcu, keep spinlock for write > - update audit_alloc_local() to use ktime_get_coarse_real_ts64() > - add nft_log support > - add call from do_exit() in audit_free() to remove contid from netns > - relegate AUDIT_CONTAINER ref= field (was op=) to debug patch > > v4 > - preface set with ghak81:"collect audit task parameters" > - add shallyn and sgrubb acks > - rename feature bitmap macro > - rename cid_valid() to audit_contid_valid() > - rename AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP > - delete audit_get_contid_list() from headers > - move work into inner if, delete "found" > - change netns contid list function names > - move exports for audit_log_contid audit_alloc_local audit_free_context to non-syscall patch > - list contids CSV > - pass in gfp flags to audit_alloc_local() (fix audit_alloc_context callers) > - use "local" in lieu of abusing in_syscall for auditsc_get_stamp() > - read_lock(&tasklist_lock) around children and thread check > - task_lock(tsk) should be taken before first check of tsk->audit > - add spin lock to contid list in aunet > - restrict /proc read to CAP_AUDIT_CONTROL > - remove set again prohibition and inherited flag > - delete contidion spelling fix from patchset, send to netdev/linux-wireless > > v3 > - switched from containerid in task_struct to audit_task_info (depends on ghak81) > - drop INVALID_CID in favour of only AUDIT_CID_UNSET > - check for !audit_task_info, throw -ENOPROTOOPT on set > - changed -EPERM to -EEXIST for parent check > - return AUDIT_CID_UNSET if !audit_enabled > - squash child/thread check patch into AUDIT_CONTAINER_ID patch > - changed -EPERM to -EBUSY for child check > - separate child and thread checks, use -EALREADY for latter > - move addition of op= from ptrace/signal patch to AUDIT_CONTAINER patch > - fix && to || bashism in ptrace/signal patch > - uninline and export function for audit_free_context() > - drop CONFIG_CHANGE, FEATURE_CHANGE, ANOM_ABEND, ANOM_SECCOMP patches > - move audit_enabled check (xt_AUDIT) > - switched from containerid list in struct net to net_generic's struct audit_net > - move containerid list iteration into audit (xt_AUDIT) > - create function to move namespace switch into audit > - switched /proc/PID/ entry from containerid to audit_containerid > - call kzalloc with GFP_ATOMIC on in_atomic() in audit_alloc_context() > - call kzalloc with GFP_ATOMIC on in_atomic() in audit_log_container_info() > - use xt_net(par) instead of sock_net(skb->sk) to get net > - switched record and field names: initial CONTAINER_ID, aux CONTAINER, field CONTID > - allow to set own contid > - open code audit_set_containerid > - add contid inherited flag > - ccontainerid and pcontainerid eliminated due to inherited flag > - change name of container list funcitons > - rename containerid to contid > - convert initial container record to syscall aux > - fix spelling mistake of contidion in net/rfkill/core.c to avoid contid name collision > > v2 > - add check for children and threads > - add network namespace container identifier list > - add NETFILTER_PKT audit container identifier logging > - patch description and documentation clean-up and example > - reap unused ppid > > Richard Guy Briggs (10): > audit: collect audit task parameters > audit: add container id > audit: read container ID of a process > audit: log container info of syscalls > audit: add contid support for signalling the audit daemon > audit: add support for non-syscall auxiliary records > audit: add containerid support for user records > audit: add containerid filtering > audit: add support for containerid to network namespaces > audit: NETFILTER_PKT: record each container ID associated with a netNS > > fs/proc/base.c | 57 +++++++- > include/linux/audit.h | 113 +++++++++++++-- > include/linux/sched.h | 7 +- > include/uapi/linux/audit.h | 9 +- > init/init_task.c | 3 +- > init/main.c | 2 + > kernel/audit.c | 325 ++++++++++++++++++++++++++++++++++++++++++-- > kernel/audit.h | 9 ++ > kernel/auditfilter.c | 47 +++++++ > kernel/auditsc.c | 90 ++++++++---- > kernel/fork.c | 1 - > kernel/nsproxy.c | 4 + > net/netfilter/nft_log.c | 11 +- > net/netfilter/xt_AUDIT.c | 11 +- > security/selinux/nlmsgtab.c | 1 + > 15 files changed, 627 insertions(+), 63 deletions(-) > > -- > 1.8.3.1 > - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > Implement kernel audit container identifier. > > This patchset is a fifth based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > The first patch was the last patch from ghak81 that was absorbed into > this patchset since its primary justification is the rest of this > patchset. > > The second patch implements the proc fs write to set the audit container > identifier of a process, emitting an AUDIT_CONTAINER_OP record to > announce the registration of that audit container identifier on that > process. This patch requires userspace support for record acceptance > and proper type display. > > The third implements reading the audit container identifier from the > proc filesystem for debugging. This patch wasn't planned for upstream > inclusion but is starting to become more likely. > > The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit > container identifier is associated with an event. This patch requires > userspace support for proper type display. > > The 5th adds audit daemon signalling provenance through audit_sig_info2. > > The 6th creates a local audit context to be able to bind a standalone > record with a locally created auxiliary record. > > The 7th patch adds audit container identifier records to the user > standalone records. > > The 8th adds audit container identifier filtering to the exit, > exclude and user lists. This patch adds the AUDIT_CONTID field and > requires auditctl userspace support for the --contid option. > > The 9th adds network namespace audit container identifier labelling > based on member tasks' audit container identifier labels. > > The 10th adds audit container identifier support to standalone netfilter > records that don't have a task context and lists each container to which > that net namespace belongs. > > Example: Set an audit container identifier of 123456 to the "sleep" task: > > sleep 2& > child=$! > echo 123456 > /proc/$child/audit_containerid; echo $? > ausearch -ts recent -m container_op > echo child:$child contid:$( cat /proc/$child/audit_containerid) > > This should produce a record such as: > > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes > > > Example: Set a filter on an audit container identifier 123459 on /tmp/tmpcontainerid: > > contid=123459 > key=tmpcontainerid > auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); close(\$tmpfile);" & > child=$! > echo $contid > /proc/$child/audit_containerid > sleep 2 > ausearch -i -ts recent -k $key > auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > rm -f /tmp/$key > > This should produce an event such as: > > type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459 > type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root > type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffffffffffff9c a1=0x5621f2b81900 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid > > Example: Test multiple containers on one netns: > > sleep 5 & > child1=$! > containerid1=123451 > echo $containerid1 > /proc/$child1/audit_containerid > sleep 5 & > child2=$! > containerid2=123452 > echo $containerid2 > /proc/$child2/audit_containerid > iptables -I INPUT -i lo -p icmp --icmp-type echo-request -j AUDIT --type accept > iptables -I INPUT -t mangle -i lo -p icmp --icmp-type echo-request -j MARK --set-mark 0x12345555 > sleep 1; > bash -c "ping -q -c 1 127.0.0.1 >/dev/null 2>&1" > sleep 1; > ausearch -i -m NETFILTER_PKT -ts boot|grep mark=0x12345555 > ausearch -i -m NETFILTER_PKT -ts boot|grep contid=|grep $containerid1|grep $containerid2 > > This should produce an event such as: > > type=NETFILTER_PKT msg=audit(03/15/2019 14:16:13.369:244) : mark=0x12345555 saddr=127.0.0.1 daddr=127.0.0.1 proto=icmp > type=CONTAINER_ID msg=audit(03/15/2019 14:16:13.369:244) : contid=123452,123451 > > > Includes the last patch of https://github.com/linux-audit/audit-kernel/issues/81 > Please see the github audit kernel issue for the main feature: > https://github.com/linux-audit/audit-kernel/issues/90 > and the kernel filter code: > https://github.com/linux-audit/audit-kernel/issues/91 > and the network support: > https://github.com/linux-audit/audit-kernel/issues/92 > Please see the github audit userspace issue for supporting record types: > https://github.com/linux-audit/audit-userspace/issues/51 > and filter code: > https://github.com/linux-audit/audit-userspace/issues/40 > Please see the github audit testsuiite issue for the test case: > https://github.com/linux-audit/audit-testsuite/issues/64 > Please see the github audit wiki for the feature overview: > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID > > > Changelog: > > v6 > - change TMPBUFLEN from 11 to 21 to cover the decimal value of contid > u64 (nhorman) > - fix bug overwriting ctx in struct audit_sig_info, move cid above > ctx[0] (nhorman) > - fix bug skipping remaining fields and not advancing bufp when copying > out contid in audit_krule_to_data (omosnacec) > - add acks, tidy commit descriptions, other formatting fixes (checkpatch > wrong on audit_log_lost) > - cast ull for u64 prints > - target_cid tracking was moved from the ptrace/signal patch to > container_op > - target ptrace and signal records were moved from the ptrace/signal > patch to container_id > - auditd signaller tracking was moved to a new AUDIT_SIGNAL_INFO2 > request and record > - ditch unnecessary list_empty() checks > - check for null net and aunet in audit_netns_contid_add() > - swap CONTAINER_OP contid/old-contid order to ease parsing > > v5 > - address loginuid and sessionid syscall scope in ghak104 > - address audit_context in CONFIG_AUDIT vs CONFIG_AUDITSYSCALL in ghak105 > - remove tty patch, addressed in ghak106 > - rebase on audit/next v5.0-rc1 > w/ghak59/ghak104/ghak103/ghak100/ghak107/ghak105/ghak106/ghak105sup > - update CONTAINER_ID to CONTAINER_OP in patch description > - move audit_context in audit_task_info to CONFIG_AUDITSYSCALL > - move audit_alloc() and audit_free() out of CONFIG_AUDITSYSCALL and into > CONFIG_AUDIT and create audit_{alloc,free}_syscall > - use plain kmem_cache_alloc() rather than kmem_cache_zalloc() in audit_alloc() > - fix audit_get_contid() declaration type error > - move audit_set_contid() from auditsc.c to audit.c > - audit_log_contid() returns void > - audit_log_contid() handed contid rather than tsk > - switch from AUDIT_CONTAINER to AUDIT_CONTAINER_ID for aux record > - move audit_log_contid(tsk/contid) & audit_contid_set(tsk)/audit_contid_valid(contid) > - switch from tsk to current > - audit_alloc_local() calls audit_log_lost() on failure to allocate a context > - add AUDIT_USER* non-syscall contid record > - cosmetic cleanup double parens, goto out on err > - ditch audit_get_ns_contid_list_lock(), fix aunet lock race > - switch from all-cpu read spinlock to rcu, keep spinlock for write > - update audit_alloc_local() to use ktime_get_coarse_real_ts64() > - add nft_log support > - add call from do_exit() in audit_free() to remove contid from netns > - relegate AUDIT_CONTAINER ref= field (was op=) to debug patch > > v4 > - preface set with ghak81:"collect audit task parameters" > - add shallyn and sgrubb acks > - rename feature bitmap macro > - rename cid_valid() to audit_contid_valid() > - rename AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP > - delete audit_get_contid_list() from headers > - move work into inner if, delete "found" > - change netns contid list function names > - move exports for audit_log_contid audit_alloc_local audit_free_context to non-syscall patch > - list contids CSV > - pass in gfp flags to audit_alloc_local() (fix audit_alloc_context callers) > - use "local" in lieu of abusing in_syscall for auditsc_get_stamp() > - read_lock(&tasklist_lock) around children and thread check > - task_lock(tsk) should be taken before first check of tsk->audit > - add spin lock to contid list in aunet > - restrict /proc read to CAP_AUDIT_CONTROL > - remove set again prohibition and inherited flag > - delete contidion spelling fix from patchset, send to netdev/linux-wireless > > v3 > - switched from containerid in task_struct to audit_task_info (depends on ghak81) > - drop INVALID_CID in favour of only AUDIT_CID_UNSET > - check for !audit_task_info, throw -ENOPROTOOPT on set > - changed -EPERM to -EEXIST for parent check > - return AUDIT_CID_UNSET if !audit_enabled > - squash child/thread check patch into AUDIT_CONTAINER_ID patch > - changed -EPERM to -EBUSY for child check > - separate child and thread checks, use -EALREADY for latter > - move addition of op= from ptrace/signal patch to AUDIT_CONTAINER patch > - fix && to || bashism in ptrace/signal patch > - uninline and export function for audit_free_context() > - drop CONFIG_CHANGE, FEATURE_CHANGE, ANOM_ABEND, ANOM_SECCOMP patches > - move audit_enabled check (xt_AUDIT) > - switched from containerid list in struct net to net_generic's struct audit_net > - move containerid list iteration into audit (xt_AUDIT) > - create function to move namespace switch into audit > - switched /proc/PID/ entry from containerid to audit_containerid > - call kzalloc with GFP_ATOMIC on in_atomic() in audit_alloc_context() > - call kzalloc with GFP_ATOMIC on in_atomic() in audit_log_container_info() > - use xt_net(par) instead of sock_net(skb->sk) to get net > - switched record and field names: initial CONTAINER_ID, aux CONTAINER, field CONTID > - allow to set own contid > - open code audit_set_containerid > - add contid inherited flag > - ccontainerid and pcontainerid eliminated due to inherited flag > - change name of container list funcitons > - rename containerid to contid > - convert initial container record to syscall aux > - fix spelling mistake of contidion in net/rfkill/core.c to avoid contid name collision > > v2 > - add check for children and threads > - add network namespace container identifier list > - add NETFILTER_PKT audit container identifier logging > - patch description and documentation clean-up and example > - reap unused ppid > > Richard Guy Briggs (10): > audit: collect audit task parameters > audit: add container id > audit: read container ID of a process > audit: log container info of syscalls > audit: add contid support for signalling the audit daemon > audit: add support for non-syscall auxiliary records > audit: add containerid support for user records > audit: add containerid filtering > audit: add support for containerid to network namespaces > audit: NETFILTER_PKT: record each container ID associated with a netNS > > fs/proc/base.c | 57 +++++++- > include/linux/audit.h | 113 +++++++++++++-- > include/linux/sched.h | 7 +- > include/uapi/linux/audit.h | 9 +- > init/init_task.c | 3 +- > init/main.c | 2 + > kernel/audit.c | 325 ++++++++++++++++++++++++++++++++++++++++++-- > kernel/audit.h | 9 ++ > kernel/auditfilter.c | 47 +++++++ > kernel/auditsc.c | 90 ++++++++---- > kernel/fork.c | 1 - > kernel/nsproxy.c | 4 + > net/netfilter/nft_log.c | 11 +- > net/netfilter/xt_AUDIT.c | 11 +- > security/selinux/nlmsgtab.c | 1 + > 15 files changed, 627 insertions(+), 63 deletions(-) > > -- > 1.8.3.1 > > I'm sorry, I've lost track of this, where have we landed on it? Are we good for inclusion? Neil
On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > Implement kernel audit container identifier. > > I'm sorry, I've lost track of this, where have we landed on it? Are we good for > inclusion? I haven't finished going through this latest revision, but unless Richard made any significant changes outside of the feedback from the v5 patchset I'm guessing we are "close". Based on discussions Richard and I had some time ago, I have always envisioned the plan as being get the kernel patchset, tests, docs ready (which Richard has been doing) and then run the actual implemented API by the userland container folks, e.g. cri-o/lxc/etc., to make sure the actual implementation is sane from their perspective. They've already seen the design, so I'm not expecting any real surprises here, but sometimes opinions change when they have actual code in front of them to play with and review. Beyond that, while the cri-o/lxc/etc. folks are looking it over, whatever additional testing we can do would be a big win. I'm thinking I'll pull it into a separate branch in the audit tree (audit/working-container ?) and include that in my secnext kernels that I build/test on a regular basis; this is also a handy way to keep it based against the current audit/next branch. If any changes are needed Richard can either chose to base those changes on audit/next or the separate audit container ID branch; that's up to him. I've done this with other big changes in other trees, e.g. SELinux, and it has worked well to get some extra testing in and keep the patchset "merge ready" while others outside the subsystem look things over.
On Mon, Apr 22, 2019 at 09:49:05AM -0400, Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > Implement kernel audit container identifier. > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we good for > > inclusion? > > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. > That all sounds good, thank you Paul. I knew you and Richard were working on it, but I somehow managed to loose track of exactly where we left this. Much Appreciated Neil > -- > paul moore > www.paul-moore.com >
On 4/22/19 9:49 AM, Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: >>> Implement kernel audit container identifier. >> I'm sorry, I've lost track of this, where have we landed on it? Are we good for >> inclusion? > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and believe this is something we can work on in the container runtimes team to implement the container auditing code in CRI-O and Podman.
On 2019-05-28 17:53, Daniel Walsh wrote: > On 4/22/19 9:49 AM, Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>> Implement kernel audit container identifier. > >> I'm sorry, I've lost track of this, where have we landed on it? Are we good for > >> inclusion? > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > believe this is something we can work on in the container runtimes team > to implement the container auditing code in CRI-O and Podman. Thanks Dan, Mrunal! - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: > > On 4/22/19 9:49 AM, Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>> Implement kernel audit container identifier. > >> I'm sorry, I've lost track of this, where have we landed on it? Are we good for > >> inclusion? > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > believe this is something we can work on in the container runtimes team > to implement the container auditing code in CRI-O and Podman. Thanks Dan. If I pulled this into a branch and built you some test kernels to play with, any idea how long it might take to get a proof of concept working on the cri-o side? FWIW, I've also reached out to some of the LXC folks I know to get their take on the API. I think if we can get two different container runtimes to give the API a thumbs-up then I think we are in good shape with respect to the userspace interface. I just finished looking over the last of the pending audit kernel patches that were queued waiting for the merge window to open so this is next on my list to look at. I plan to start doing that tonight/tomorrow, and as long as the changes between v5/v6 are not that big, it shouldn't take too long.
On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: > > On 4/22/19 9:49 AM, Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > >>> Implement kernel audit container identifier. > > >> > > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > > >> good for inclusion? > > > > > > I haven't finished going through this latest revision, but unless > > > Richard made any significant changes outside of the feedback from the > > > v5 patchset I'm guessing we are "close". > > > > > > Based on discussions Richard and I had some time ago, I have always > > > envisioned the plan as being get the kernel patchset, tests, docs > > > ready (which Richard has been doing) and then run the actual > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > to make sure the actual implementation is sane from their perspective. > > > They've already seen the design, so I'm not expecting any real > > > surprises here, but sometimes opinions change when they have actual > > > code in front of them to play with and review. > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > whatever additional testing we can do would be a big win. I'm > > > thinking I'll pull it into a separate branch in the audit tree > > > (audit/working-container ?) and include that in my secnext kernels > > > that I build/test on a regular basis; this is also a handy way to keep > > > it based against the current audit/next branch. If any changes are > > > needed Richard can either chose to base those changes on audit/next or > > > the separate audit container ID branch; that's up to him. I've done > > > this with other big changes in other trees, e.g. SELinux, and it has > > > worked well to get some extra testing in and keep the patchset "merge > > > ready" while others outside the subsystem look things over. > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > believe this is something we can work on in the container runtimes team > > to implement the container auditing code in CRI-O and Podman. > > Thanks Dan. If I pulled this into a branch and built you some test > kernels to play with, any idea how long it might take to get a proof > of concept working on the cri-o side? We'd need to merge user space patches and let them use that instead of the raw interface. I'm not going to merge user space until we are pretty sure the patch is going into the kernel. -Steve > FWIW, I've also reached out to some of the LXC folks I know to get > their take on the API. I think if we can get two different container > runtimes to give the API a thumbs-up then I think we are in good shape > with respect to the userspace interface. > > I just finished looking over the last of the pending audit kernel > patches that were queued waiting for the merge window to open so this > is next on my list to look at. I plan to start doing that > tonight/tomorrow, and as long as the changes between v5/v6 are not > that big, it shouldn't take too long.
On 2019-05-28 19:00, Steve Grubb wrote: > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: > > > On 4/22/19 9:49 AM, Paul Moore wrote: > > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> > wrote: > > > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > >>> Implement kernel audit container identifier. > > > >> > > > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > > > >> good for inclusion? > > > > > > > > I haven't finished going through this latest revision, but unless > > > > Richard made any significant changes outside of the feedback from the > > > > v5 patchset I'm guessing we are "close". > > > > > > > > Based on discussions Richard and I had some time ago, I have always > > > > envisioned the plan as being get the kernel patchset, tests, docs > > > > ready (which Richard has been doing) and then run the actual > > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > > to make sure the actual implementation is sane from their perspective. > > > > They've already seen the design, so I'm not expecting any real > > > > surprises here, but sometimes opinions change when they have actual > > > > code in front of them to play with and review. > > > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > > whatever additional testing we can do would be a big win. I'm > > > > thinking I'll pull it into a separate branch in the audit tree > > > > (audit/working-container ?) and include that in my secnext kernels > > > > that I build/test on a regular basis; this is also a handy way to keep > > > > it based against the current audit/next branch. If any changes are > > > > needed Richard can either chose to base those changes on audit/next or > > > > the separate audit container ID branch; that's up to him. I've done > > > > this with other big changes in other trees, e.g. SELinux, and it has > > > > worked well to get some extra testing in and keep the patchset "merge > > > > ready" while others outside the subsystem look things over. > > > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > > believe this is something we can work on in the container runtimes team > > > to implement the container auditing code in CRI-O and Podman. > > > > Thanks Dan. If I pulled this into a branch and built you some test > > kernels to play with, any idea how long it might take to get a proof > > of concept working on the cri-o side? > > We'd need to merge user space patches and let them use that instead of the > raw interface. I'm not going to merge user space until we are pretty sure the > patch is going into the kernel. I have an f29 test rpm of the userspace bits if that helps for testing: http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ Here's what it contains (minus the last patch): https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > -Steve > > > FWIW, I've also reached out to some of the LXC folks I know to get > > their take on the API. I think if we can get two different container > > runtimes to give the API a thumbs-up then I think we are in good shape > > with respect to the userspace interface. > > > > I just finished looking over the last of the pending audit kernel > > patches that were queued waiting for the merge window to open so this > > is next on my list to look at. I plan to start doing that > > tonight/tomorrow, and as long as the changes between v5/v6 are not > > that big, it shouldn't take too long. - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > On 2019-05-28 19:00, Steve Grubb wrote: >> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: >>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: >>>> On 4/22/19 9:49 AM, Paul Moore wrote: >>>>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> >> wrote: >>>>>> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: >>>>>>> Implement kernel audit container identifier. >>>>>> I'm sorry, I've lost track of this, where have we landed on it? Are we >>>>>> good for inclusion? >>>>> I haven't finished going through this latest revision, but unless >>>>> Richard made any significant changes outside of the feedback from the >>>>> v5 patchset I'm guessing we are "close". >>>>> >>>>> Based on discussions Richard and I had some time ago, I have always >>>>> envisioned the plan as being get the kernel patchset, tests, docs >>>>> ready (which Richard has been doing) and then run the actual >>>>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., >>>>> to make sure the actual implementation is sane from their perspective. >>>>> They've already seen the design, so I'm not expecting any real >>>>> surprises here, but sometimes opinions change when they have actual >>>>> code in front of them to play with and review. >>>>> >>>>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, >>>>> whatever additional testing we can do would be a big win. I'm >>>>> thinking I'll pull it into a separate branch in the audit tree >>>>> (audit/working-container ?) and include that in my secnext kernels >>>>> that I build/test on a regular basis; this is also a handy way to keep >>>>> it based against the current audit/next branch. If any changes are >>>>> needed Richard can either chose to base those changes on audit/next or >>>>> the separate audit container ID branch; that's up to him. I've done >>>>> this with other big changes in other trees, e.g. SELinux, and it has >>>>> worked well to get some extra testing in and keep the patchset "merge >>>>> ready" while others outside the subsystem look things over. >>>> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and >>>> believe this is something we can work on in the container runtimes team >>>> to implement the container auditing code in CRI-O and Podman. >>> Thanks Dan. If I pulled this into a branch and built you some test >>> kernels to play with, any idea how long it might take to get a proof >>> of concept working on the cri-o side? >> We'd need to merge user space patches and let them use that instead of the >> raw interface. I'm not going to merge user space until we are pretty sure the >> patch is going into the kernel. > I have an f29 test rpm of the userspace bits if that helps for testing: > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > Here's what it contains (minus the last patch): > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > >> -Steve >> >>> FWIW, I've also reached out to some of the LXC folks I know to get >>> their take on the API. I think if we can get two different container >>> runtimes to give the API a thumbs-up then I think we are in good shape >>> with respect to the userspace interface. >>> >>> I just finished looking over the last of the pending audit kernel >>> patches that were queued waiting for the merge window to open so this >>> is next on my list to look at. I plan to start doing that >>> tonight/tomorrow, and as long as the changes between v5/v6 are not >>> that big, it shouldn't take too long. > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 Our current thoughts are to put the setting of the ID inside of conmon, and then launching the OCI Runtime. In a perfect world this would happen in the OCI Runtime, but we have no controls over different OCI Runtimes. By putting it into conmon, then CRI-O and Podman will automatically get the container id support. After we have this we have to plumb it back up through the contianer engines to be able to easily report the link between the Container UUID and The Kernel Container Audit ID.
On Tue, May 28, 2019 at 8:44 PM Richard Guy Briggs <rgb@redhat.com> wrote: > On 2019-05-28 19:00, Steve Grubb wrote: > > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: ... > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > > > believe this is something we can work on in the container runtimes team > > > > to implement the container auditing code in CRI-O and Podman. > > > > > > Thanks Dan. If I pulled this into a branch and built you some test > > > kernels to play with, any idea how long it might take to get a proof > > > of concept working on the cri-o side? > > > > We'd need to merge user space patches and let them use that instead of the > > raw interface. I'm not going to merge user space until we are pretty sure the > > patch is going into the kernel. > > I have an f29 test rpm of the userspace bits if that helps for testing: > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > Here's what it contains (minus the last patch): > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 Yes, exactly. Just as I plan to start making some test kernels for people to play with (assuming v6 looks okay), I think it would be good if Steve could make a test build of the latest audit userspace with the audit container ID patches. It really shouldn't be that hard, and the benefits should far outweigh any time spent generating the tree/builds.
On Wed, May 29, 2019 at 8:03 AM Daniel Walsh <dwalsh@redhat.com> wrote: > > On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > > On 2019-05-28 19:00, Steve Grubb wrote: > >> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > >>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: > >>>> On 4/22/19 9:49 AM, Paul Moore wrote: > >>>>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> > >> wrote: > >>>>>> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>>>>>> Implement kernel audit container identifier. > >>>>>> I'm sorry, I've lost track of this, where have we landed on it? Are we > >>>>>> good for inclusion? > >>>>> I haven't finished going through this latest revision, but unless > >>>>> Richard made any significant changes outside of the feedback from the > >>>>> v5 patchset I'm guessing we are "close". > >>>>> > >>>>> Based on discussions Richard and I had some time ago, I have always > >>>>> envisioned the plan as being get the kernel patchset, tests, docs > >>>>> ready (which Richard has been doing) and then run the actual > >>>>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., > >>>>> to make sure the actual implementation is sane from their perspective. > >>>>> They've already seen the design, so I'm not expecting any real > >>>>> surprises here, but sometimes opinions change when they have actual > >>>>> code in front of them to play with and review. > >>>>> > >>>>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, > >>>>> whatever additional testing we can do would be a big win. I'm > >>>>> thinking I'll pull it into a separate branch in the audit tree > >>>>> (audit/working-container ?) and include that in my secnext kernels > >>>>> that I build/test on a regular basis; this is also a handy way to keep > >>>>> it based against the current audit/next branch. If any changes are > >>>>> needed Richard can either chose to base those changes on audit/next or > >>>>> the separate audit container ID branch; that's up to him. I've done > >>>>> this with other big changes in other trees, e.g. SELinux, and it has > >>>>> worked well to get some extra testing in and keep the patchset "merge > >>>>> ready" while others outside the subsystem look things over. > >>>> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > >>>> believe this is something we can work on in the container runtimes team > >>>> to implement the container auditing code in CRI-O and Podman. > >>> Thanks Dan. If I pulled this into a branch and built you some test > >>> kernels to play with, any idea how long it might take to get a proof > >>> of concept working on the cri-o side? > >> We'd need to merge user space patches and let them use that instead of the > >> raw interface. I'm not going to merge user space until we are pretty sure the > >> patch is going into the kernel. > > I have an f29 test rpm of the userspace bits if that helps for testing: > > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > > > Here's what it contains (minus the last patch): > > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > > > >> -Steve > >> > >>> FWIW, I've also reached out to some of the LXC folks I know to get > >>> their take on the API. I think if we can get two different container > >>> runtimes to give the API a thumbs-up then I think we are in good shape > >>> with respect to the userspace interface. > >>> > >>> I just finished looking over the last of the pending audit kernel > >>> patches that were queued waiting for the merge window to open so this > >>> is next on my list to look at. I plan to start doing that > >>> tonight/tomorrow, and as long as the changes between v5/v6 are not > >>> that big, it shouldn't take too long. > > - RGB > > > > -- > > Richard Guy Briggs <rgb@redhat.com> > > Sr. S/W Engineer, Kernel Security, Base Operating Systems > > Remote, Ottawa, Red Hat Canada > > IRC: rgb, SunRaycer > > Voice: +1.647.777.2635, Internal: (81) 32635 > > Our current thoughts are to put the setting of the ID inside of conmon, > and then launching the OCI Runtime. In a perfect world this would > happen in the OCI Runtime, but we have no controls over different OCI > Runtimes. > > By putting it into conmon, then CRI-O and Podman will automatically get > the container id support. After we have this we have to plumb it back > up through the contianer engines to be able to easily report the link > between the Container UUID and The Kernel Container Audit ID. I'm glad you guys have a plan, that's encouraging, but sadly I have no idea about the level of complexity/difficulty involved in modifying the various container bits for a proof-of-concept? Are we talking a week or two? A month? More?
On 5/29/19 9:17 AM, Paul Moore wrote: > On Wed, May 29, 2019 at 8:03 AM Daniel Walsh <dwalsh@redhat.com> wrote: >> On 5/28/19 8:43 PM, Richard Guy Briggs wrote: >>> On 2019-05-28 19:00, Steve Grubb wrote: >>>> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: >>>>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: >>>>>> On 4/22/19 9:49 AM, Paul Moore wrote: >>>>>>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> >>>> wrote: >>>>>>>> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: >>>>>>>>> Implement kernel audit container identifier. >>>>>>>> I'm sorry, I've lost track of this, where have we landed on it? Are we >>>>>>>> good for inclusion? >>>>>>> I haven't finished going through this latest revision, but unless >>>>>>> Richard made any significant changes outside of the feedback from the >>>>>>> v5 patchset I'm guessing we are "close". >>>>>>> >>>>>>> Based on discussions Richard and I had some time ago, I have always >>>>>>> envisioned the plan as being get the kernel patchset, tests, docs >>>>>>> ready (which Richard has been doing) and then run the actual >>>>>>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., >>>>>>> to make sure the actual implementation is sane from their perspective. >>>>>>> They've already seen the design, so I'm not expecting any real >>>>>>> surprises here, but sometimes opinions change when they have actual >>>>>>> code in front of them to play with and review. >>>>>>> >>>>>>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, >>>>>>> whatever additional testing we can do would be a big win. I'm >>>>>>> thinking I'll pull it into a separate branch in the audit tree >>>>>>> (audit/working-container ?) and include that in my secnext kernels >>>>>>> that I build/test on a regular basis; this is also a handy way to keep >>>>>>> it based against the current audit/next branch. If any changes are >>>>>>> needed Richard can either chose to base those changes on audit/next or >>>>>>> the separate audit container ID branch; that's up to him. I've done >>>>>>> this with other big changes in other trees, e.g. SELinux, and it has >>>>>>> worked well to get some extra testing in and keep the patchset "merge >>>>>>> ready" while others outside the subsystem look things over. >>>>>> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and >>>>>> believe this is something we can work on in the container runtimes team >>>>>> to implement the container auditing code in CRI-O and Podman. >>>>> Thanks Dan. If I pulled this into a branch and built you some test >>>>> kernels to play with, any idea how long it might take to get a proof >>>>> of concept working on the cri-o side? >>>> We'd need to merge user space patches and let them use that instead of the >>>> raw interface. I'm not going to merge user space until we are pretty sure the >>>> patch is going into the kernel. >>> I have an f29 test rpm of the userspace bits if that helps for testing: >>> http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ >>> >>> Here's what it contains (minus the last patch): >>> https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 >>> >>>> -Steve >>>> >>>>> FWIW, I've also reached out to some of the LXC folks I know to get >>>>> their take on the API. I think if we can get two different container >>>>> runtimes to give the API a thumbs-up then I think we are in good shape >>>>> with respect to the userspace interface. >>>>> >>>>> I just finished looking over the last of the pending audit kernel >>>>> patches that were queued waiting for the merge window to open so this >>>>> is next on my list to look at. I plan to start doing that >>>>> tonight/tomorrow, and as long as the changes between v5/v6 are not >>>>> that big, it shouldn't take too long. >>> - RGB >>> >>> -- >>> Richard Guy Briggs <rgb@redhat.com> >>> Sr. S/W Engineer, Kernel Security, Base Operating Systems >>> Remote, Ottawa, Red Hat Canada >>> IRC: rgb, SunRaycer >>> Voice: +1.647.777.2635, Internal: (81) 32635 >> Our current thoughts are to put the setting of the ID inside of conmon, >> and then launching the OCI Runtime. In a perfect world this would >> happen in the OCI Runtime, but we have no controls over different OCI >> Runtimes. >> >> By putting it into conmon, then CRI-O and Podman will automatically get >> the container id support. After we have this we have to plumb it back >> up through the contianer engines to be able to easily report the link >> between the Container UUID and The Kernel Container Audit ID. > I'm glad you guys have a plan, that's encouraging, but sadly I have no > idea about the level of complexity/difficulty involved in modifying > the various container bits for a proof-of-concept? Are we talking a > week or two? A month? More? > If we had the kernel and the libaudit api, it would involve a small effort in conmon, I would figure a few days for a POC. Getting the hole wiring into CRI-O and Podman, would be a little more effort.
On Wed, May 29, 2019 at 10:07 AM Daniel Walsh <dwalsh@redhat.com> wrote: > On 5/29/19 9:17 AM, Paul Moore wrote: > > On Wed, May 29, 2019 at 8:03 AM Daniel Walsh <dwalsh@redhat.com> wrote: > >> On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > >>> On 2019-05-28 19:00, Steve Grubb wrote: > >>>> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > >>>>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh <dwalsh@redhat.com> wrote: > >>>>>> On 4/22/19 9:49 AM, Paul Moore wrote: > >>>>>>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> > >>>> wrote: > >>>>>>>> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>>>>>>>> Implement kernel audit container identifier. > >>>>>>>> I'm sorry, I've lost track of this, where have we landed on it? Are we > >>>>>>>> good for inclusion? > >>>>>>> I haven't finished going through this latest revision, but unless > >>>>>>> Richard made any significant changes outside of the feedback from the > >>>>>>> v5 patchset I'm guessing we are "close". > >>>>>>> > >>>>>>> Based on discussions Richard and I had some time ago, I have always > >>>>>>> envisioned the plan as being get the kernel patchset, tests, docs > >>>>>>> ready (which Richard has been doing) and then run the actual > >>>>>>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., > >>>>>>> to make sure the actual implementation is sane from their perspective. > >>>>>>> They've already seen the design, so I'm not expecting any real > >>>>>>> surprises here, but sometimes opinions change when they have actual > >>>>>>> code in front of them to play with and review. > >>>>>>> > >>>>>>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, > >>>>>>> whatever additional testing we can do would be a big win. I'm > >>>>>>> thinking I'll pull it into a separate branch in the audit tree > >>>>>>> (audit/working-container ?) and include that in my secnext kernels > >>>>>>> that I build/test on a regular basis; this is also a handy way to keep > >>>>>>> it based against the current audit/next branch. If any changes are > >>>>>>> needed Richard can either chose to base those changes on audit/next or > >>>>>>> the separate audit container ID branch; that's up to him. I've done > >>>>>>> this with other big changes in other trees, e.g. SELinux, and it has > >>>>>>> worked well to get some extra testing in and keep the patchset "merge > >>>>>>> ready" while others outside the subsystem look things over. > >>>>>> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > >>>>>> believe this is something we can work on in the container runtimes team > >>>>>> to implement the container auditing code in CRI-O and Podman. > >>>>> Thanks Dan. If I pulled this into a branch and built you some test > >>>>> kernels to play with, any idea how long it might take to get a proof > >>>>> of concept working on the cri-o side? > >>>> We'd need to merge user space patches and let them use that instead of the > >>>> raw interface. I'm not going to merge user space until we are pretty sure the > >>>> patch is going into the kernel. > >>> I have an f29 test rpm of the userspace bits if that helps for testing: > >>> http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > >>> > >>> Here's what it contains (minus the last patch): > >>> https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > >>> > >>>> -Steve > >>>> > >>>>> FWIW, I've also reached out to some of the LXC folks I know to get > >>>>> their take on the API. I think if we can get two different container > >>>>> runtimes to give the API a thumbs-up then I think we are in good shape > >>>>> with respect to the userspace interface. > >>>>> > >>>>> I just finished looking over the last of the pending audit kernel > >>>>> patches that were queued waiting for the merge window to open so this > >>>>> is next on my list to look at. I plan to start doing that > >>>>> tonight/tomorrow, and as long as the changes between v5/v6 are not > >>>>> that big, it shouldn't take too long. > >>> - RGB > >>> > >>> -- > >>> Richard Guy Briggs <rgb@redhat.com> > >>> Sr. S/W Engineer, Kernel Security, Base Operating Systems > >>> Remote, Ottawa, Red Hat Canada > >>> IRC: rgb, SunRaycer > >>> Voice: +1.647.777.2635, Internal: (81) 32635 > >> Our current thoughts are to put the setting of the ID inside of conmon, > >> and then launching the OCI Runtime. In a perfect world this would > >> happen in the OCI Runtime, but we have no controls over different OCI > >> Runtimes. > >> > >> By putting it into conmon, then CRI-O and Podman will automatically get > >> the container id support. After we have this we have to plumb it back > >> up through the contianer engines to be able to easily report the link > >> between the Container UUID and The Kernel Container Audit ID. > > I'm glad you guys have a plan, that's encouraging, but sadly I have no > > idea about the level of complexity/difficulty involved in modifying > > the various container bits for a proof-of-concept? Are we talking a > > week or two? A month? More? > > > If we had the kernel and the libaudit api, it would involve a small > effort in conmon, I would figure a few days for a POC. Getting the > hole wiring into CRI-O and Podman, would be a little more effort. That's great. Stay tuned ...
On Mon, Apr 22, 2019 at 9:49 AM Paul Moore <paul@paul-moore.com> wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > Implement kernel audit container identifier. > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we good for > > inclusion? > > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. I just sent my feedback on the v6 patchset, and it's small: basically three patches with "one-liner" changes needed. Richard, it's your call on how you want to proceed from here. You can post a v7 incorporating the feedback, or since the tweaks are so minor, you can post fixup patches; the former being more comprehensive, the later being quicker to review and digest. Regardless of that, while we are waiting on a prototype from the container folks, I think it would be good to pull this into a working branch in the audit repo (as mentioned above), unless you would prefer to keep it as a patchset on the mailing list? If you want to go with the working branch approach, I'll keep the branch fresh and (re)based against audit/next and if we notice any problems you can just submit fixes against that branch (depending on the issue they can be fixup patches, or proper patches). My hope is that this will enable the process to move quicker as we get near the finish line.
On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore <paul@paul-moore.com> wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> wrote: > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > Implement kernel audit container identifier. > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > good for inclusion? > > > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > I just sent my feedback on the v6 patchset, and it's small: basically > three patches with "one-liner" changes needed. > > Richard, it's your call on how you want to proceed from here. You can > post a v7 incorporating the feedback, or since the tweaks are so > minor, you can post fixup patches; the former being more > comprehensive, the later being quicker to review and digest. > Regardless of that, while we are waiting on a prototype from the > container folks, I think it would be good to pull this into a working > branch in the audit repo (as mentioned above), unless you would prefer > to keep it as a patchset on the mailing list? Personally, I'd like to see this on a branch so that it's easier to build a kernel locally for testing. -Steve > If you want to go with > the working branch approach, I'll keep the branch fresh and (re)based > against audit/next and if we notice any problems you can just submit > fixes against that branch (depending on the issue they can be fixup > patches, or proper patches). My hope is that this will enable the > process to move quicker as we get near the finish line.
On Thu, May 30, 2019 at 9:08 AM Steve Grubb <sgrubb@redhat.com> wrote: > On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore <paul@paul-moore.com> wrote: > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> > wrote: > > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > > Implement kernel audit container identifier. > > > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > > good for inclusion? > > > > > > I haven't finished going through this latest revision, but unless > > > Richard made any significant changes outside of the feedback from the > > > v5 patchset I'm guessing we are "close". > > > > > > Based on discussions Richard and I had some time ago, I have always > > > envisioned the plan as being get the kernel patchset, tests, docs > > > ready (which Richard has been doing) and then run the actual > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > to make sure the actual implementation is sane from their perspective. > > > They've already seen the design, so I'm not expecting any real > > > surprises here, but sometimes opinions change when they have actual > > > code in front of them to play with and review. > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > whatever additional testing we can do would be a big win. I'm > > > thinking I'll pull it into a separate branch in the audit tree > > > (audit/working-container ?) and include that in my secnext kernels > > > that I build/test on a regular basis; this is also a handy way to keep > > > it based against the current audit/next branch. If any changes are > > > needed Richard can either chose to base those changes on audit/next or > > > the separate audit container ID branch; that's up to him. I've done > > > this with other big changes in other trees, e.g. SELinux, and it has > > > worked well to get some extra testing in and keep the patchset "merge > > > ready" while others outside the subsystem look things over. > > > > I just sent my feedback on the v6 patchset, and it's small: basically > > three patches with "one-liner" changes needed. > > > > Richard, it's your call on how you want to proceed from here. You can > > post a v7 incorporating the feedback, or since the tweaks are so > > minor, you can post fixup patches; the former being more > > comprehensive, the later being quicker to review and digest. > > Regardless of that, while we are waiting on a prototype from the > > container folks, I think it would be good to pull this into a working > > branch in the audit repo (as mentioned above), unless you would prefer > > to keep it as a patchset on the mailing list? > > Personally, I'd like to see this on a branch so that it's easier to build a > kernel locally for testing. FWIW, if Richard does prefer for me to pull it into a working branch I plan to include it in my secnext builds both to make it easier to test regularly and to make the changes available to people who don't want to build their own kernel. * http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html
On 2019-05-30 09:35, Paul Moore wrote: > On Thu, May 30, 2019 at 9:08 AM Steve Grubb <sgrubb@redhat.com> wrote: > > On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore <paul@paul-moore.com> wrote: > > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@tuxdriver.com> > > wrote: > > > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > > > Implement kernel audit container identifier. > > > > > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > > > good for inclusion? > > > > > > > > I haven't finished going through this latest revision, but unless > > > > Richard made any significant changes outside of the feedback from the > > > > v5 patchset I'm guessing we are "close". > > > > > > > > Based on discussions Richard and I had some time ago, I have always > > > > envisioned the plan as being get the kernel patchset, tests, docs > > > > ready (which Richard has been doing) and then run the actual > > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > > to make sure the actual implementation is sane from their perspective. > > > > They've already seen the design, so I'm not expecting any real > > > > surprises here, but sometimes opinions change when they have actual > > > > code in front of them to play with and review. > > > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > > whatever additional testing we can do would be a big win. I'm > > > > thinking I'll pull it into a separate branch in the audit tree > > > > (audit/working-container ?) and include that in my secnext kernels > > > > that I build/test on a regular basis; this is also a handy way to keep > > > > it based against the current audit/next branch. If any changes are > > > > needed Richard can either chose to base those changes on audit/next or > > > > the separate audit container ID branch; that's up to him. I've done > > > > this with other big changes in other trees, e.g. SELinux, and it has > > > > worked well to get some extra testing in and keep the patchset "merge > > > > ready" while others outside the subsystem look things over. > > > > > > I just sent my feedback on the v6 patchset, and it's small: basically > > > three patches with "one-liner" changes needed. > > > > > > Richard, it's your call on how you want to proceed from here. You can > > > post a v7 incorporating the feedback, or since the tweaks are so > > > minor, you can post fixup patches; the former being more > > > comprehensive, the later being quicker to review and digest. > > > Regardless of that, while we are waiting on a prototype from the > > > container folks, I think it would be good to pull this into a working > > > branch in the audit repo (as mentioned above), unless you would prefer > > > to keep it as a patchset on the mailing list? > > > > Personally, I'd like to see this on a branch so that it's easier to build a > > kernel locally for testing. > > FWIW, if Richard does prefer for me to pull it into a working branch I > plan to include it in my secnext builds both to make it easier to test > regularly and to make the changes available to people who don't want > to build their own kernel. Sure, let's do a working branch. I'll answer the issues in respective threads... > * http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html > > -- > paul moore > www.paul-moore.com > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
Implement kernel audit container identifier. This patchset is a fifth based on the proposal document (V3) posted: https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html The first patch was the last patch from ghak81 that was absorbed into this patchset since its primary justification is the rest of this patchset. The second patch implements the proc fs write to set the audit container identifier of a process, emitting an AUDIT_CONTAINER_OP record to announce the registration of that audit container identifier on that process. This patch requires userspace support for record acceptance and proper type display. The third implements reading the audit container identifier from the proc filesystem for debugging. This patch wasn't planned for upstream inclusion but is starting to become more likely. The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit container identifier is associated with an event. This patch requires userspace support for proper type display. The 5th adds audit daemon signalling provenance through audit_sig_info2. The 6th creates a local audit context to be able to bind a standalone record with a locally created auxiliary record. The 7th patch adds audit container identifier records to the user standalone records. The 8th adds audit container identifier filtering to the exit, exclude and user lists. This patch adds the AUDIT_CONTID field and requires auditctl userspace support for the --contid option. The 9th adds network namespace audit container identifier labelling based on member tasks' audit container identifier labels. The 10th adds audit container identifier support to standalone netfilter records that don't have a task context and lists each container to which that net namespace belongs. Example: Set an audit container identifier of 123456 to the "sleep" task: sleep 2& child=$! echo 123456 > /proc/$child/audit_containerid; echo $? ausearch -ts recent -m container_op echo child:$child contid:$( cat /proc/$child/audit_containerid) This should produce a record such as: type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root uid=root tty=ttyS0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash exe=/usr/bin/bash res=yes Example: Set a filter on an audit container identifier 123459 on /tmp/tmpcontainerid: contid=123459 key=tmpcontainerid auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); close(\$tmpfile);" & child=$! echo $contid > /proc/$child/audit_containerid sleep 2 ausearch -i -ts recent -k $key auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key rm -f /tmp/$key This should produce an event such as: type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459 type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffffffffffff9c a1=0x5621f2b81900 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid Example: Test multiple containers on one netns: sleep 5 & child1=$! containerid1=123451 echo $containerid1 > /proc/$child1/audit_containerid sleep 5 & child2=$! containerid2=123452 echo $containerid2 > /proc/$child2/audit_containerid iptables -I INPUT -i lo -p icmp --icmp-type echo-request -j AUDIT --type accept iptables -I INPUT -t mangle -i lo -p icmp --icmp-type echo-request -j MARK --set-mark 0x12345555 sleep 1; bash -c "ping -q -c 1 127.0.0.1 >/dev/null 2>&1" sleep 1; ausearch -i -m NETFILTER_PKT -ts boot|grep mark=0x12345555 ausearch -i -m NETFILTER_PKT -ts boot|grep contid=|grep $containerid1|grep $containerid2 This should produce an event such as: type=NETFILTER_PKT msg=audit(03/15/2019 14:16:13.369:244) : mark=0x12345555 saddr=127.0.0.1 daddr=127.0.0.1 proto=icmp type=CONTAINER_ID msg=audit(03/15/2019 14:16:13.369:244) : contid=123452,123451 Includes the last patch of https://github.com/linux-audit/audit-kernel/issues/81 Please see the github audit kernel issue for the main feature: https://github.com/linux-audit/audit-kernel/issues/90 and the kernel filter code: https://github.com/linux-audit/audit-kernel/issues/91 and the network support: https://github.com/linux-audit/audit-kernel/issues/92 Please see the github audit userspace issue for supporting record types: https://github.com/linux-audit/audit-userspace/issues/51 and filter code: https://github.com/linux-audit/audit-userspace/issues/40 Please see the github audit testsuiite issue for the test case: https://github.com/linux-audit/audit-testsuite/issues/64 Please see the github audit wiki for the feature overview: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID Changelog: v6 - change TMPBUFLEN from 11 to 21 to cover the decimal value of contid u64 (nhorman) - fix bug overwriting ctx in struct audit_sig_info, move cid above ctx[0] (nhorman) - fix bug skipping remaining fields and not advancing bufp when copying out contid in audit_krule_to_data (omosnacec) - add acks, tidy commit descriptions, other formatting fixes (checkpatch wrong on audit_log_lost) - cast ull for u64 prints - target_cid tracking was moved from the ptrace/signal patch to container_op - target ptrace and signal records were moved from the ptrace/signal patch to container_id - auditd signaller tracking was moved to a new AUDIT_SIGNAL_INFO2 request and record - ditch unnecessary list_empty() checks - check for null net and aunet in audit_netns_contid_add() - swap CONTAINER_OP contid/old-contid order to ease parsing v5 - address loginuid and sessionid syscall scope in ghak104 - address audit_context in CONFIG_AUDIT vs CONFIG_AUDITSYSCALL in ghak105 - remove tty patch, addressed in ghak106 - rebase on audit/next v5.0-rc1 w/ghak59/ghak104/ghak103/ghak100/ghak107/ghak105/ghak106/ghak105sup - update CONTAINER_ID to CONTAINER_OP in patch description - move audit_context in audit_task_info to CONFIG_AUDITSYSCALL - move audit_alloc() and audit_free() out of CONFIG_AUDITSYSCALL and into CONFIG_AUDIT and create audit_{alloc,free}_syscall - use plain kmem_cache_alloc() rather than kmem_cache_zalloc() in audit_alloc() - fix audit_get_contid() declaration type error - move audit_set_contid() from auditsc.c to audit.c - audit_log_contid() returns void - audit_log_contid() handed contid rather than tsk - switch from AUDIT_CONTAINER to AUDIT_CONTAINER_ID for aux record - move audit_log_contid(tsk/contid) & audit_contid_set(tsk)/audit_contid_valid(contid) - switch from tsk to current - audit_alloc_local() calls audit_log_lost() on failure to allocate a context - add AUDIT_USER* non-syscall contid record - cosmetic cleanup double parens, goto out on err - ditch audit_get_ns_contid_list_lock(), fix aunet lock race - switch from all-cpu read spinlock to rcu, keep spinlock for write - update audit_alloc_local() to use ktime_get_coarse_real_ts64() - add nft_log support - add call from do_exit() in audit_free() to remove contid from netns - relegate AUDIT_CONTAINER ref= field (was op=) to debug patch v4 - preface set with ghak81:"collect audit task parameters" - add shallyn and sgrubb acks - rename feature bitmap macro - rename cid_valid() to audit_contid_valid() - rename AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP - delete audit_get_contid_list() from headers - move work into inner if, delete "found" - change netns contid list function names - move exports for audit_log_contid audit_alloc_local audit_free_context to non-syscall patch - list contids CSV - pass in gfp flags to audit_alloc_local() (fix audit_alloc_context callers) - use "local" in lieu of abusing in_syscall for auditsc_get_stamp() - read_lock(&tasklist_lock) around children and thread check - task_lock(tsk) should be taken before first check of tsk->audit - add spin lock to contid list in aunet - restrict /proc read to CAP_AUDIT_CONTROL - remove set again prohibition and inherited flag - delete contidion spelling fix from patchset, send to netdev/linux-wireless v3 - switched from containerid in task_struct to audit_task_info (depends on ghak81) - drop INVALID_CID in favour of only AUDIT_CID_UNSET - check for !audit_task_info, throw -ENOPROTOOPT on set - changed -EPERM to -EEXIST for parent check - return AUDIT_CID_UNSET if !audit_enabled - squash child/thread check patch into AUDIT_CONTAINER_ID patch - changed -EPERM to -EBUSY for child check - separate child and thread checks, use -EALREADY for latter - move addition of op= from ptrace/signal patch to AUDIT_CONTAINER patch - fix && to || bashism in ptrace/signal patch - uninline and export function for audit_free_context() - drop CONFIG_CHANGE, FEATURE_CHANGE, ANOM_ABEND, ANOM_SECCOMP patches - move audit_enabled check (xt_AUDIT) - switched from containerid list in struct net to net_generic's struct audit_net - move containerid list iteration into audit (xt_AUDIT) - create function to move namespace switch into audit - switched /proc/PID/ entry from containerid to audit_containerid - call kzalloc with GFP_ATOMIC on in_atomic() in audit_alloc_context() - call kzalloc with GFP_ATOMIC on in_atomic() in audit_log_container_info() - use xt_net(par) instead of sock_net(skb->sk) to get net - switched record and field names: initial CONTAINER_ID, aux CONTAINER, field CONTID - allow to set own contid - open code audit_set_containerid - add contid inherited flag - ccontainerid and pcontainerid eliminated due to inherited flag - change name of container list funcitons - rename containerid to contid - convert initial container record to syscall aux - fix spelling mistake of contidion in net/rfkill/core.c to avoid contid name collision v2 - add check for children and threads - add network namespace container identifier list - add NETFILTER_PKT audit container identifier logging - patch description and documentation clean-up and example - reap unused ppid Richard Guy Briggs (10): audit: collect audit task parameters audit: add container id audit: read container ID of a process audit: log container info of syscalls audit: add contid support for signalling the audit daemon audit: add support for non-syscall auxiliary records audit: add containerid support for user records audit: add containerid filtering audit: add support for containerid to network namespaces audit: NETFILTER_PKT: record each container ID associated with a netNS fs/proc/base.c | 57 +++++++- include/linux/audit.h | 113 +++++++++++++-- include/linux/sched.h | 7 +- include/uapi/linux/audit.h | 9 +- init/init_task.c | 3 +- init/main.c | 2 + kernel/audit.c | 325 ++++++++++++++++++++++++++++++++++++++++++-- kernel/audit.h | 9 ++ kernel/auditfilter.c | 47 +++++++ kernel/auditsc.c | 90 ++++++++---- kernel/fork.c | 1 - kernel/nsproxy.c | 4 + net/netfilter/nft_log.c | 11 +- net/netfilter/xt_AUDIT.c | 11 +- security/selinux/nlmsgtab.c | 1 + 15 files changed, 627 insertions(+), 63 deletions(-)