Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Sat, 23 Sep 2023 18:58:04 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     Casey Schaufler <casey@schaufler-ca.com>, paul@paul-moore.com,
        linux-security-module@vger.kernel.org, jmorris@namei.org,
        serge@hallyn.com, john.johansen@canonical.com,
        stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, mic@digikod.net,
        Dave Chinner <david@fromorbit.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name
Message-ID: <202309231838.CB16E6B5@keescook>
References: <20230912205658.3432-1-casey@schaufler-ca.com>
 <20230912205658.3432-2-casey@schaufler-ca.com>
 <1f5e725d-58b6-eca2-97dc-d7c1209ff167@I-love.SAKURA.ne.jp>
 <568c0730-b458-04b4-dbfa-77da1758aa05@schaufler-ca.com>
 <94743c22-bc76-e741-e577-3e0845423f69@I-love.SAKURA.ne.jp>
 <6df9f8b8-5653-09a5-ae0a-6526016abaff@schaufler-ca.com>
 <ec37cd2f-24ee-3273-c253-58d480569117@I-love.SAKURA.ne.jp>
 <202309200803.1911A584@keescook>
 <af696700-ae4b-346e-4c52-3a7a21b0f46c@I-love.SAKURA.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <af696700-ae4b-346e-4c52-3a7a21b0f46c@I-love.SAKURA.ne.jp>
Precedence: bulk

On Sat, Sep 23, 2023 at 01:46:35PM +0900, Tetsuo Handa wrote:
> On 2023/09/21 0:08, Kees Cook wrote:
> > I feel like you are willfully not listening to us when we say that this
> > doesn't block out of tree LSMs. Again, there is nothing here that stops
> > it. To prove this point, here is an out of tree LSM that works with this
> > series. So let's move from theoretical to practical: given this example,
> > why do you think out of tree LSMs are blocked?
> 
> Because an LSM ID value

But my example includes one.

> > diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> > index eeda59a77c02..23b7a8f79cef 100644
> > --- a/include/uapi/linux/lsm.h
> > +++ b/include/uapi/linux/lsm.h
> > @@ -63,6 +63,8 @@ struct lsm_ctx {
> >  #define LSM_ID_BPF		110
> >  #define LSM_ID_LANDLOCK		111
> >  
> > +#define LSM_ID_GOAT		1138
> > +
> >  /*
> >   * LSM_ATTR_XXX definitions identify different LSM attributes
> >   * which are used in the kernel's LSM userspace API. Support
> 
> is assigned to LSM only when that LSM became no longer out of tree.

Why? My example code will work just fine. The only possible reason
it could be awkward would be if an out of tree LSM became so useful
that the author decided to upstream it, and risked colliding with an
existing LSM id. But lsm_id::id is a u64 (not an enum!), so there is
a HUGE space available. If out of tree LSMs used the epoch time they
were first authored as their id, the chances of a collision would be
approaching zero. There isn't an out of tree LSM written every second,
but if there were, it would take 584 billion years to run out of LSM ids.

And, as mentioned several times before, this is _not a new problem_, and
exists for out of tree syscalls, out of tree prctls, etc. I even DID
this for the Yama LSM when it looked like it wasn't going to get
upstream in the early days. Its prctl number _is not sequential_:

include/uapi/linux/prctl.h:#define PR_SET_PTRACER 0x59616d61

(And you'll see 0x59616d61 in ASCII is "Yama"; my effort to avoid
collision.)

So, there is both ability (u64) and precedent (Yama) for this. Having an
LSM id is _not_ a blocker for out of tree LSMs, and I've given the proof.

-Kees

-- 
Kees Cook