Received: by 10.192.165.148 with SMTP id m20csp42140imm; Wed, 9 May 2018 08:29:57 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp01M7mRCs9emI1rmUx3thMSDbV1JHNplDKxaa2f3Uwgv3FbfknoDgJQkWJtObJ9N4nDSoP X-Received: by 2002:a65:5686:: with SMTP id v6-v6mr35097498pgs.92.1525879797037; Wed, 09 May 2018 08:29:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525879797; cv=none; d=google.com; s=arc-20160816; b=mO5EArtTWxevgh6cnXRVs11+Xe1hL3/KvepM7joESvFzpsJXX5n5rN4PEMpTOztrQG 5nV54zHxQXV4queePFyZHEdxsqE49+pZaxzQg6OrJB2CQLhkoO8QQOn0wYtPtXOCCXys 6zxFVtLuyUPUbfWpwFzYnhmsnNOLsni5UGXbx63Hy8gsjG7QtCpyomCemHuvuUQt9+Q3 lGU8qOB2cwtklWr9Ed+O/pS2adovKvmC7uAvgGFgVWIqJXTbJLpDACpYBSGRnoK331Bv cZSki0+wg1KvjYQfOHypb9S3vdmzXAH8xnPhhQKZRUBspkRjZuYSWp9FeiaOWoIJJ0KY peQQ== 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=3IAyftaC1Ml6LQOAiPiSvkhB3gAlda2ZoXnWtBfTh30=; b=MXP1TGtw4UvjiVm6FCSgZ4hELnGZOiuqVigSl35PBAYHbE25LVPVLcBrSdQlIkfgS8 mqmQPcGHU8q7cMcYfjYSjF/uft5dKQHIiIhtJ0/pDJ5gIt8cmHH2D7jhr8oAGNCgAqRd b7frKmcwjQnWQjq7yCCNQqMXgC4YHhhly4W/debtvSwXShJMwPuSy1gYdqn+BlO3wrGH rTxdPaz36LSpU5+VSdS9VVv7NQHObQEZlzsAI73Vj7umLY9SFZKO29jDhg21BF66NHm+ LgBZEobeGix7bieaAxyz3J7yEyC4mhrbpzX1tkAR3y5yUF1PTl3u6jApT78OwnhGkOHK O+cQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=iM8w9+mK; 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 v11-v6si21317335pgo.643.2018.05.09.08.29.41; Wed, 09 May 2018 08:29:56 -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=iM8w9+mK; 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 S935406AbeEIP3D (ORCPT + 99 others); Wed, 9 May 2018 11:29:03 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:44917 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935397AbeEIP3B (ORCPT ); Wed, 9 May 2018 11:29:01 -0400 Received: by mail-lf0-f67.google.com with SMTP id h197-v6so51523780lfg.11 for ; Wed, 09 May 2018 08:29:00 -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=3IAyftaC1Ml6LQOAiPiSvkhB3gAlda2ZoXnWtBfTh30=; b=iM8w9+mK7bvUCsFP5zfuQ4E5QAu1Vs8W5fYGejw2D1WYcs/9Jiy0BkAzwP02kzZg0m ysc7MN2R+G/T+rz18IG3B51j7KWI3QWnK6SgaRi5oKIh0tq/WFMJbX7N0UhHqFpDXZTU wDC7R9PniB0b7BXuojmhsg/ufCLHe6taaBsVR1HvmIsDabi0r2rfuNhz4SO1eKa/3/w/ LopJygvlGjcj6vr1Au5bE7DuL5YNhjL+HzEbxybyCq/odCsYjxQYKmSA1fLXHe+CNKVS gA0ckKaRSZFc0n8AJ+lrWtR4Ncy0oL9YRnKvaX0JrJ+q/Ko//x9VXGq6JClredPVSJ4B yJQg== 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=3IAyftaC1Ml6LQOAiPiSvkhB3gAlda2ZoXnWtBfTh30=; b=X4El3FaoSASCVu9LmbqFm47WYSXbUkuK2j3lVVwOgxwGQDiWjHWJmKd6SEAVw4jUNE PkTxxUyGIvNMBRXGnwbKfMQUVsxrPSNLfmvruY2DrFRluNo0R6ejhaOkzT14CHRPOX3y USR2h7coR+an2JfLy53yqii+rgz3SYlBCZB856V4nuiiCuk5zZUUi1S6Ju6++z+ieIRJ 0ahRds5DPMpO7dPHXTp5secACMtgAwCgXMwNr0sPsRCrQpvZDy+CUpg+g6iUAL6+8Jx6 Q3OukTJUECpljE8TORNiqqOBAvwQZP8CaLeLQ9HXPWBTHXFqoE+18gt2hFVBKu5WLCgY 1P9w== X-Gm-Message-State: ALQs6tB4EOb35f50RkolK2lEzAtfjUu+skHA4n3ij1k/TqR/H3BS+/AQ Djq7l2vcHT8Sl4vdgScAny5KPiNNNo5xw9rM2SZP X-Received: by 2002:a2e:8518:: with SMTP id j24-v6mr32669285lji.12.1525879739380; Wed, 09 May 2018 08:28:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a947:0:0:0:0:0 with HTTP; Wed, 9 May 2018 08:28:58 -0700 (PDT) X-Originating-IP: [68.177.129.184] In-Reply-To: <0e43c5135c197209b3189032d538244571e7443d.1525466167.git.rgb@redhat.com> References: <0e43c5135c197209b3189032d538244571e7443d.1525466167.git.rgb@redhat.com> From: Paul Moore Date: Wed, 9 May 2018 11:28:58 -0400 Message-ID: Subject: Re: [PATCH ghak81 RFC V1 3/5] audit: use inline function to get audit context To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , Linux NetDev Upstream Mailing List , Netfilter Devel List , Linux Security Module list , Integrity Measurement Architecture , SElinux list , Eric Paris , Steve Grubb , Ingo Molnar , David Howells 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, May 4, 2018 at 4:54 PM, Richard Guy Briggs wrote: > Recognizing that the audit context is an internal audit value, use an > access function to retrieve the audit context pointer for the task > rather than reaching directly into the task struct to get it. > > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 16 ++++++++--- > include/net/xfrm.h | 2 +- > kernel/audit.c | 4 +-- > kernel/audit_watch.c | 2 +- > kernel/auditsc.c | 52 ++++++++++++++++++------------------ > net/bridge/netfilter/ebtables.c | 2 +- > net/core/dev.c | 2 +- > net/netfilter/x_tables.c | 2 +- > net/netlabel/netlabel_user.c | 2 +- > security/integrity/ima/ima_api.c | 2 +- > security/integrity/integrity_audit.c | 2 +- > security/lsm_audit.c | 2 +- > security/selinux/hooks.c | 4 +-- > security/selinux/selinuxfs.c | 6 ++--- > security/selinux/ss/services.c | 12 ++++----- > 15 files changed, 60 insertions(+), 52 deletions(-) > > diff --git a/include/linux/audit.h b/include/linux/audit.h > index 5f86f7c..93e4c61 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -235,26 +235,30 @@ extern void __audit_inode_child(struct inode *parent, > extern void __audit_seccomp(unsigned long syscall, long signr, int code); > extern void __audit_ptrace(struct task_struct *t); > > +static inline struct audit_context *audit_context(struct task_struct *task) > +{ > + return task->audit_context; > +} Another case where I think I agree with everything here on principle, especially when one considers it in the larger context of the audit container ID work. However, I think we might be able to somply this a bit by eliminating the parameter to the new audit_context() helper and making it always reference the current task_struct. Based on this patch it would appear that this change would work for all callers except for audit_take_context() and __audit_syscall_entry(), both of which are contained within the core audit code and are enough of a special case that I think it is acceptable for them to access the context directly. I'm trying to think of reasons why a non-audit kernel subsystem would ever need to access the audit context of a process other than current and I can't think of any ... removing the task_struct pointer might help prevent mistakes/abuse in the future. > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 6e3ceb9..a4bbdcc 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -836,7 +836,7 @@ static inline struct audit_context *audit_take_context(struct task_struct *tsk, > int return_valid, > long return_code) > { > - struct audit_context *context = tsk->audit_context; > + struct audit_context *context = audit_context(tsk); > > if (!context) > return NULL; > @@ -1510,7 +1510,7 @@ void __audit_syscall_entry(int major, unsigned long a1, unsigned long a2, > unsigned long a3, unsigned long a4) > { > struct task_struct *tsk = current; > - struct audit_context *context = tsk->audit_context; > + struct audit_context *context = audit_context(tsk); > enum audit_state state; > > if (!audit_enabled || !context) -- paul moore www.paul-moore.com