Received: by 10.192.165.156 with SMTP id m28csp71866imm; Wed, 18 Apr 2018 17:33:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+dT18Gk/v6QFCoyxYKaYRLOg8099KZ4bTbibMguAcURHQTs7X6o4FexqEW97wtGxLE51b+ X-Received: by 10.99.6.66 with SMTP id 63mr3359818pgg.10.1524098022709; Wed, 18 Apr 2018 17:33:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524098022; cv=none; d=google.com; s=arc-20160816; b=nHv3GWPCfDAxCcKe2VLm4x1c+dCFkfqJKPUoOOq5pZm9CKaapWlmxx97I+ErvZfG4A a1UDo1knRzJE5HvIHXSiCb1AGFS1Em/tj0xs4pkti3kKK9EAwkDC9e4rD360k+botsGr Mdn9k6yt1ZtwW1S6Cxchof3b98xvlPITegoRl30hG15O8v+z0EbBd+9efKkwmwdarCyY u7oBG+N0+uD7CLA95cqlGKU68LCqZdTlkFCKEhDQzFvqGhNJip2aHByQZ/s6bbgfuN8R YgSS8Seu1jo6pMXLmseJOw/FjKjsRFSp64Vv/OmuJNSAzZBreMOJoPK9D+t3pzyUrAJv K0KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Qtn6+lNqjil/v2BDJd6yI6q/mL5dpWbcCSCkjyk8dvw=; b=xzz1qSHNgTBVTfpL0zaxWdl+qqgoEPTY7sTXWP0GyNQ+OlJC6CI1B5CQ9qIexa+Ogg PkVJzIrWQOFti8O8TehIySROiTr84ipB0+RTMV/NH6bC0SwI2pO1nCoNDYd/uiGsoRPV orBcvNgYZfvw8GnB4/vXXbRY/yh8oBi/VCu1X+6ZiAICZHwH88LedXmKwz92IANYovYY 1NSMuFX1XnTr47tSp2TS+pmrv9ZLeH9+l5qw/RTlJjOL+3+JTArYgSa7tDzqErz0i1D7 ECE1FZC2TZyFEQvA6UeOBRDo53l8SV+uw/QpqK416HuKStbwezdJCKdi+6HMwTEuglDp VnTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=GjFjprvp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k189si2065303pgc.388.2018.04.18.17.33.28; Wed, 18 Apr 2018 17:33:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=GjFjprvp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753102AbeDSAcV (ORCPT + 99 others); Wed, 18 Apr 2018 20:32:21 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:42871 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752514AbeDSAcS (ORCPT ); Wed, 18 Apr 2018 20:32:18 -0400 Received: by mail-lf0-f67.google.com with SMTP id x130-v6so5219577lff.9 for ; Wed, 18 Apr 2018 17:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qtn6+lNqjil/v2BDJd6yI6q/mL5dpWbcCSCkjyk8dvw=; b=GjFjprvpgwxQy5hlyqgvTlFUCY8FtCdra/OHZRVQDtHB0j1niH4AxJamehAPwsqb69 yZ5a0WRNrymQ1F8Uk5Up9rVZpgj6BjJwM+vXKF8KTfcJlSV+wLJUXLCRocM05sTW0Aay VE9/v5Xddz/SQa+ruE2sdWJMX4xvW/O3YklOeA4qhCHTyZ4sn60q8NVVSiFzdhymhMao xnbrS17g8C80hI0phTka0CBfj2VP80Ay9sL4RsRKZj8UZehrX7otIqR67Vj5y4W5g4pr 2GaMdAPtrzNtwWZrzgbAWml//GlF0E7KzShsg7YEPZ5vsnxrY3QXewgEgSprJE2wV2Fi 0TeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qtn6+lNqjil/v2BDJd6yI6q/mL5dpWbcCSCkjyk8dvw=; b=KIvCH2+HbkZWDLskfHgPo2bXWGidKeZdxfldcwf2cPbh31VM3DTJWbdaXLjsZ48E4c E1S8+kgCW3bBexbWzh3q9vjP7niSlqww77QOS9niOSOjdQSJtSmMN3AW0poD5pveVSJL oc6I4vl0kbSeEhZwDq3qdpBuLNK7OQA9uzM/9/fOIHl3qMa33hL7RGoooQnjk2ntfgGK eI5cvsfzeBSGuBBTzHA9WHtqrCaTQNmqxu+9+U9qc4HgwJGRZwLH8+YQgemtCBqeo/PH xtn/tI23uosiiR87sCVRlm2fCepdpP0Mx7u/M/Bn9tHJIsvuA4q/r5lbqOWxkNZWo5kH zWGw== X-Gm-Message-State: ALQs6tCJIZyryvlm984FHeIpBhSjDcsDMDKiogbJ0bcOXMixNistclbc rZvDZwnefQQIaT+mFcmn08YNfZmtd5XxVhSfL40Q X-Received: by 2002:a19:c6cc:: with SMTP id w195-v6mr2706522lff.40.1524097936811; Wed, 18 Apr 2018 17:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a5c3:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 17:32:15 -0700 (PDT) X-Originating-IP: [108.20.156.165] In-Reply-To: <8c7ff567377f4a83edac48e962c1b5b824b523c8.1521179281.git.rgb@redhat.com> References: <8c7ff567377f4a83edac48e962c1b5b824b523c8.1521179281.git.rgb@redhat.com> From: Paul Moore Date: Wed, 18 Apr 2018 20:32:15 -0400 Message-ID: Subject: Re: [RFC PATCH ghak32 V2 05/13] audit: add containerid support for ptrace and signals To: Richard Guy Briggs Cc: cgroups@vger.kernel.org, containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, ebiederm@xmission.com, luto@kernel.org, jlayton@redhat.com, carlos@redhat.com, dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com, Eric Paris , serge@hallyn.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: > Add container ID support to ptrace and signals. In particular, the "op" > field provides a way to label the auxiliary record to which it is > associated. > > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 16 +++++++++++----- > kernel/audit.c | 12 ++++++++---- > kernel/audit.h | 2 ++ > kernel/auditsc.c | 19 +++++++++++++++---- > 4 files changed, 36 insertions(+), 13 deletions(-) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index a12f21f..b238be5 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -142,6 +142,7 @@ struct audit_net { > kuid_t audit_sig_uid = INVALID_UID; > pid_t audit_sig_pid = -1; > u32 audit_sig_sid = 0; > +u64 audit_sig_cid = INVALID_CID; > > /* Records can be lost in several ways: > 0) [suppressed in audit_alloc] > @@ -1438,6 +1439,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh) > memcpy(sig_data->ctx, ctx, len); > security_release_secctx(ctx, len); > } > + sig_data->cid = audit_sig_cid; > audit_send_reply(skb, seq, AUDIT_SIGNAL_INFO, 0, 0, > sig_data, sizeof(*sig_data) + len); > kfree(sig_data); > @@ -2051,20 +2053,22 @@ void audit_log_session_info(struct audit_buffer *ab) > > /* > * audit_log_container_info - report container info > - * @tsk: task to be recorded > * @context: task or local context for record > + * @op: containerid string description > + * @containerid: container ID to report > */ > -int audit_log_container_info(struct task_struct *tsk, struct audit_context *context) > +int audit_log_container_info(struct audit_context *context, > + char *op, u64 containerid) > { > struct audit_buffer *ab; > > - if (!audit_containerid_set(tsk)) > + if (!cid_valid(containerid)) > return 0; > /* Generate AUDIT_CONTAINER_INFO with container ID */ > ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER_INFO); > if (!ab) > return -ENOMEM; > - audit_log_format(ab, "contid=%llu", audit_get_containerid(tsk)); > + audit_log_format(ab, "op=%s contid=%llu", op, containerid); > audit_log_end(ab); > return 0; > } Let's get these changes into the first patch where audit_log_container_info() is defined. Why? This inserts a new field into the record which is a no-no. Yes, it is one single patchset, but they are still separate patches and who knows which patches a given distribution and/or tree may decide to backport. > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 2bba324..2932ef1 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -113,6 +113,7 @@ struct audit_aux_data_pids { > kuid_t target_uid[AUDIT_AUX_PIDS]; > unsigned int target_sessionid[AUDIT_AUX_PIDS]; > u32 target_sid[AUDIT_AUX_PIDS]; > + u64 target_cid[AUDIT_AUX_PIDS]; > char target_comm[AUDIT_AUX_PIDS][TASK_COMM_LEN]; > int pid_count; > }; > @@ -1422,21 +1423,27 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts > for (aux = context->aux_pids; aux; aux = aux->next) { > struct audit_aux_data_pids *axs = (void *)aux; > > - for (i = 0; i < axs->pid_count; i++) > + for (i = 0; i < axs->pid_count; i++) { > + char axsn[sizeof("aux0xN ")]; > + > + sprintf(axsn, "aux0x%x", i); > if (audit_log_pid_context(context, axs->target_pid[i], > axs->target_auid[i], > axs->target_uid[i], > axs->target_sessionid[i], > axs->target_sid[i], > - axs->target_comm[i])) > + axs->target_comm[i]) > + && audit_log_container_info(context, axsn, axs->target_cid[i])) Shouldn't this be an OR instead of an AND? > call_panic = 1; > + } > } > > if (context->target_pid && > audit_log_pid_context(context, context->target_pid, > context->target_auid, context->target_uid, > context->target_sessionid, > - context->target_sid, context->target_comm)) > + context->target_sid, context->target_comm) > + && audit_log_container_info(context, "target", context->target_cid)) Same question. > call_panic = 1; > > if (context->pwd.dentry && context->pwd.mnt) { -- paul moore www.paul-moore.com