[PATCH v2 2/3] proc: query LSMs for introspective mem access (if PROC_MEM_FORCE_ALWAYS)

[Paul Moore]

On Fri, Aug 28, 2026 at 9:21 AM Jann Horn <jannh at google.com> wrote:
> On Fri, Aug 28, 2026 at 3:03 PM Jann Horn <jannh at google.com> wrote:
> > On Fri, Aug 28, 2026 at 3:10 AM Paul Moore <paul at paul-moore.com> wrote:
> > > Beyond that, we really try to avoid making LSM hook calls conditional.  It
> > > can limit what an LSM can enforce, it tends to be a bit more fragile, and
> > > it adds some unnecessary work in the case where CONFIG_SECURITY is
> > > disabled.  I would suggest passing 'opened_by_owner' flag as a second
> > > parameter to the LSM hook and calling the hook unconditionally in the
> > > default switch case as a replacement for the 'return true;' statement.  I
> > > understand it may seem a bit odd, but we try to make the LSM interface as
> > > generic as possible with respect to different models and this is one way
> >
> > I guess I can do that, but then the question becomes, what other modes
> > of using the LSM hook that don't currently exist in the kernel should
> > I be supporting with this? I can make this a parameter, but any LSM
> > policy that actually uses the parameter in a different way would
> > probably be buggy/inconsistent, unless other new LSM hooks are added.
> >
> > If your intent is to make the hook work for any /proc/$pid/mem access,
> > including when the caller is ptrace-attached, then I guess I have to
> > move around the security hook call in proc_mem_foll_force() a little
> > bit. I guess I'll do that in v3, though I really don't like trying to
> > come up with a reasonable in-kernel API contract for a scenario that
> > currently has zero users.
>
> I started thinking about how to implement this, and an annoying aspect
> about this is:
>
> Currently, I only have to look at the credentials of the opener of the
> file - that is both the subject and object of the access. But if I
> want to provide a hook that works for any /proc/$pid/mem access, and
> want the hook to know what the object of the access is, and do it
> race-free, then I would need to grab the creds of the target task in
> mm_access(), bubble them up into proc_mem_open() and mem_open() (which
> will require touching all the callers of mm_access() and
> proc_mem_open()), store them into mem_private there, then let
> proc_mem_foll_force() extract the creds from there. All that would be
> unused code.
>
> Do you think I should just not provide credentials for the target, and
> document "if opened_by_owner is true, the subject credentials are also
> the object credentials; if opened_by_owner is false, you don't get to
> know what the object is"?

>From my perspective there are good reasons for not making the LSM hook
conditional (see previous emails), but I will happily admit that we
don't have any (?) good reasons for attempting to generalize this hook
beyond what it is at this point in time.  I would suggest documenting
the limitations when opened_by_owner is false and leave it at that; if
someone wants to implement something that requires more
hooks/parameters we can always revisit this.

-- 
paul-moore.com