From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A82B3C433DB for ; Mon, 4 Jan 2021 14:23:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 703BF207BC for ; Mon, 4 Jan 2021 14:23:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727353AbhADOXQ (ORCPT ); Mon, 4 Jan 2021 09:23:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727136AbhADOXP (ORCPT ); Mon, 4 Jan 2021 09:23:15 -0500 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95745C061793; Mon, 4 Jan 2021 06:22:34 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id o13so64720527lfr.3; Mon, 04 Jan 2021 06:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kXTFfeMRZQQpjX/bUjX/VUuqwPxBKyg8TYI+r24zwMc=; b=bL9IjbB8aRoM2Bbdkox5AoGHJ7LmMDhG5X87RhacQffOkK4RDKh9GzBDzsLftnPqjg sjV80SnDAn9HsjTEPA9YkwRPxUyVdnQBmUdeKBb/07ve4M5yhoiJkpnkolbCB1bB7yLF 4fIkPhcyWaaJmR3N99kkDhOhqel2j0sPbAgo9zH5cf3zqTnSF3E6HkO8dYrEZDfVrgtX gDhvY0tDgHRPyUCGvBLSvEtKVY+nsdJCQTjGbY4qSfCx/Db8rW+TaQoVlZPjyrkfzeSc n7HoTrR9GUEHLA+Ged8gOt/vkI8SWGZXUvdoC4ZYDH0yQ+Vph9fZX5iKRbus6nq3x+7I EIxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kXTFfeMRZQQpjX/bUjX/VUuqwPxBKyg8TYI+r24zwMc=; b=PCljmN9+XRc/74lw5nDuZN9IyJItbYtakmH3+ACqyXdxWOPSk3XxWybE+iUmy+Vhyp vKSN7m8KmA/GAbZaS8HpZdA4HM09qjBv6P/8ihpU26oltpHJLyRqiX5UYtzgJGSmB6y8 +PyL6XyfFWMNfpUXSJi7hdoB+QBmvqNyxx3/+9uTHRVeagjpVljdcF8dYDje4tLC4Arf TxWln3AGKP9yCQ9SZtXh36M5KL3FAkPJBHDfFJ02MLRtsAX7txbGBpBR4XTNLHY0lr8x lZ9WURDAx2nO/RtS4pY2VA8h2pyPVaG2DKCoT55dmf4dvXeDNTZLkRZ3WgEuBLW2Gzm1 DxBw== X-Gm-Message-State: AOAM531vh05Sv1/5stTvVsV5vl8mGRzAQEeDqh5jMCRYPOCVtZ3wV1Kj UmFzHnoazsGveylUV45Iwx79dtgaPYd9X4euxZ8= X-Google-Smtp-Source: ABdhPJytbIseJCFq7LhrJXQnsC4iBKXOUNOS6w9t+SOinAywUYi8J+1uiDqH+aTMStFRoDVoeD38KQIiVG21U4iPnlg= X-Received: by 2002:a19:c786:: with SMTP id x128mr35713651lff.323.1609770153039; Mon, 04 Jan 2021 06:22:33 -0800 (PST) MIME-Version: 1.0 References: <20201219000616.197585-1-stephen.s.brennan@oracle.com> <20201219000616.197585-2-stephen.s.brennan@oracle.com> In-Reply-To: From: Stephen Smalley Date: Mon, 4 Jan 2021 09:22:22 -0500 Message-ID: Subject: Re: [PATCH v3 2/2] proc: ensure security hook is called after exec To: Stephen Brennan Cc: Alexey Dobriyan , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , SElinux list , Casey Schaufler , Eric Biederman , Alexander Viro , Linux FS Devel , linux-kernel , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 4, 2021 at 9:16 AM Stephen Smalley wrote: > > On Fri, Dec 18, 2020 at 7:06 PM Stephen Brennan > wrote: > > > > Smack needs its security_task_to_inode() hook to be called when a task > > execs a new executable. Store the self_exec_id of the task and call the > > hook via pid_update_inode() whenever the exec_id changes. > > > > Signed-off-by: Stephen Brennan > > Sorry to be late in responding, but the proc inode security structure > needs to be updated not only upon a context-changing exec but also > upon a setcon(3) aka write to /proc/self/attr/current just like the > uid/gid needs to be updated not only upon a setuid exec but also upon > a setuid(2). I'm also unclear as to why you can't call > security_task_to_inode during RCU lookup; it doesn't block/sleep > AFAICT. > All it does is take a spinlock and update a few fields. You could also optimize this by comparing the sid similar to how the uid/gid are compared and only updating it within the hook if it has not yet been initialized or has changed since it was originally set.