Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAHC9VhRkn65jgVW5fTRWOrDe+dXQD-_-BTN+rZ8Kcq5qxFi45Q@mail.gmail.com>
 <CAHk-=wjs1S_63iF509z6-ZJSXbm5rASYYykMAcOLzjP46eYuRQ@mail.gmail.com>
In-Reply-To: <CAHk-=wjs1S_63iF509z6-ZJSXbm5rASYYykMAcOLzjP46eYuRQ@mail.gmail.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Mon, 22 Feb 2021 17:57:44 -0500
Message-ID: <CAHC9VhRSYNcaji0E5PhKap0z3Fdszqa5vZy5R3Jdxzr-GtABbA@mail.gmail.com>
Subject: Re: [GIT PULL] SELinux patches for v5.12
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        SElinux list <selinux@vger.kernel.org>,
        LSM List <linux-security-module@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Feb 21, 2021 at 8:07 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Feb 15, 2021 at 1:57 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > - Add support for labeling anonymous inodes, and extend this new
> > support to userfaultfd.
>
> I've pulled this, but I just have to note how much I hate the function
> names. "secure inode"? There's nothing particularly secure about the
> resulting inode.
>
> It's gone through the security layer init, that doesn't make it
> "secure". ALL normal inodes go through it, are all those inodes thus
> "secure"? No.
>
> Naming matters, and I think these things are actively mis-named
> implying things that they aren't.

I don't disagree that naming is important, I would only add,
non-sarcastically, that naming is hard (as a coworker likes to remind
me on a regular basis).

My personal take on the "secure" function variant is that it provides
some indication that this is tied to a LSM hook.  For better or worse,
all of the LSM hooks start off with "security_" and most (all?) of the
LSM blob void pointers in various structs throughout the kernel are
named "security".  While arguments can be made about the merits of
that depending on how you define "security", the fact remains that
they are named that way.  If you, or anyone else reading this, has
another suggestion for the function names I'm listening ...

-- 
paul moore
www.paul-moore.com