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

On Mon, Aug 24, 2026 at 07:43:02PM +0200, Jann Horn wrote:
> On Mon, Aug 24, 2026 at 7:33 PM Lorenzo Stoakes (ARM) <[email protected]> wrote:
> > On Mon, Aug 24, 2026 at 07:06:04PM +0200, Jann Horn wrote:
> > > On Fri, Aug 21, 2026 at 8:52 PM Lorenzo Stoakes (ARM) <[email protected]> wrote:
> > > > The sharing a /proc/mem fd seems like that's a pretty dumb thing to do in
> > > > general :) but I guess you have to protect against that.
> > >
> > > Yeah, it's a kinda weird thing to do...
> >
> > Yup :)) but I guess we have to account for people doing weird stuff...
> >
> > In this case (I do mention it in a reply elsewhere I think) it does seem
> > like perhaps you should separately check for current->mm != mm of (what was
> > originally /proc/self/mm)?
>
> I wouldn't want to do it for this access check, since that could lead
> to "confused deputy" problems.

I guess if it got the decision wrong somehow that'd be a problem? Or wrongly
OK'd it on one level but then that led to the fd being passed on assumption it
was OK to do it or something?

>
> > Or at least it seems like a crazy thing to be able to get full access to
> > another process's memory (that it... gave you though).
> >
> > Anyway perhaps overthinking it :)
>
> Hm, yes, though I guess that is kind of orthogonal.
>
> For what it's worth, SELinux can prevent such things happening across
> domain boundaries - it enforces that, in the SELinux ruleset, the
> process calling read()/write() on an FD is granted FILE__READ /
> FILE__WRITE permission to the file's inode.

Ah OK that's good that it's at least possible to check for this class of problem
so the rest is moot then :)


--
Cheers, Lorenzo