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.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C5632C43612 for ; Mon, 14 Jan 2019 09:02:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E03220663 for ; Mon, 14 Jan 2019 09:02:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726615AbfANJCI (ORCPT ); Mon, 14 Jan 2019 04:02:08 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:45273 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbfANJCH (ORCPT ); Mon, 14 Jan 2019 04:02:07 -0500 Received: by mail-oi1-f193.google.com with SMTP id y1so17230315oie.12 for ; Mon, 14 Jan 2019 01:02:07 -0800 (PST) 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=lOIatw4SDxXlMhwoMxxKnNLegq1MeDbiRrhaVNYfQ8g=; b=WQcTuaY4MYHgVKCGIinm+OxQToGSRquroF4HiWriQW6YPE/oSJAMUC8J/pGrEy7r2T PHoO/nZzTB7x7K6ENIgKdEwdfLh+ewAoR79UWDcsxhVvum6mNIFCjV91yCtKAjC9XPgK Cplo723XAzOxu4ZhydmGKpD5Vb/AzZaiH8i3W9PAt//FPTcq4eoSRMoJRr+yyDJLlOzW QYOvRvvM4XVsABlc79+RKDPwyDwZwLb2Nna8hF7Sv7uJAP7spp1HEu+Hr6Y2eqB+IPqy LMK5AaJZU4WoZa7/ZrNYqm1RekOxATjk+K5eJEEeZNXo/P2Wnl6wwx5SsrpRZY/WrDix jt7g== X-Gm-Message-State: AJcUukc+H2ECrJoV+JAAmOYkcVYV+WN2oCM2Fojr3c8Yef8xiwuGpbrA WnFE3kSw+X5Si/yQ5maBDZNaQtcPbJGvt0k1cI6QvQ== X-Google-Smtp-Source: ALg8bN4YjX+3nucIkM+ERdxv0qMahRKKDlduj1VhLSNsa1EB2VnnNzCTF/ybeDEhvl+v9iX76L97c5mMFM40bsKNWQs= X-Received: by 2002:aca:3b43:: with SMTP id i64mr15806119oia.156.1547456526855; Mon, 14 Jan 2019 01:02:06 -0800 (PST) MIME-Version: 1.0 References: <20190109162830.8309-1-omosnace@redhat.com> <20190109162830.8309-2-omosnace@redhat.com> In-Reply-To: From: Ondrej Mosnacek Date: Mon, 14 Jan 2019 10:01:56 +0100 Message-ID: Subject: Re: [PATCH v2 1/3] LSM: Add new hook for generic node initialization To: Paul Moore Cc: Casey Schaufler , selinux@vger.kernel.org, Stephen Smalley , Linux Security Module list , Greg Kroah-Hartman , Tejun Heo , linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Fri, Jan 11, 2019 at 2:57 AM Paul Moore wrote: > On Wed, Jan 9, 2019 at 12:08 PM Casey Schaufler wrote: > > On 1/9/2019 8:28 AM, Ondrej Mosnacek wrote: > > > This patch introduces a new security hook that is intended for > > > initializing the security data for newly created pseudo filesystem > > > objects (such as kernfs nodes) that provide a way of storing a > > > non-default security context, but need to operate independently from > > > mounts. > > > > > > The main motivation is to allow kernfs nodes to inherit the context of > > > the parent under SELinux, similar to the behavior of > > > security_inode_init_security(). Other LSMs may implement their own logic > > > for handling the creation of new nodes. > > > > > > Signed-off-by: Ondrej Mosnacek > > > --- > > > include/linux/lsm_hooks.h | 30 ++++++++++++++++++++++++++++++ > > > include/linux/security.h | 14 ++++++++++++++ > > > security/security.c | 10 ++++++++++ > > > 3 files changed, 54 insertions(+) > > > > > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > > index aaeb7fa24dc4..3a2399d7721f 100644 > > > --- a/include/linux/lsm_hooks.h > > > +++ b/include/linux/lsm_hooks.h > > > @@ -429,6 +429,31 @@ > > > * to abort the copy up. Note that the caller is responsible for reading > > > * and writing the xattrs as this hook is merely a filter. > > > * > > > + * Security hooks for special file-like objects > > > + * > > > + * @object_init_security: > > > > I don't like the name. There are too many things that are "objects" > > for this to be meaningful. I also dislike seeing names like > > security_object_init_security. How about init_from_parent? If there's > > never a chance that it will be used anywhere but with kernfs, it could > > be kernfs_node_init. The existing set of hook names are sufficiently > > confusing without adding to the mystery. TBH, I wasn't completely satisfied with the name either, I was hoping to get some better suggestions along the way. > > I like the naming similarity with inode_init_security(), that seems > helpful. Although I somewhat understand you concern about the generic > "object". Could you live with kernfs_init_security()? If another fs > adopts it, we could always changing the name later if needed. I decided to leave out kernfs out of the name, since it ended up looking quite generic (nothing particularly kernfs-specific in the argument list). On second thought, I'm starting to prefer kernfs_init_security(), considering the very low likelihood that it would be useful elsewhere and that it will likely end up having some more arguments tailored specifically for kernfs in the next revisions (w.r.t. the cover letter discussion). -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.