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

On Tue, Aug 25, 2026 at 05:00:59PM +0200, Jann Horn wrote:
> On Tue, Aug 25, 2026 at 4:24 PM Lorenzo Stoakes (ARM) <[email protected]> wrote:
> > On Tue, Aug 25, 2026 at 04:08:42PM +0200, Jann Horn wrote:
> > > On Tue, Aug 25, 2026 at 3:42 PM Lorenzo Stoakes (ARM) <[email protected]> wrote:
> > > > 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?
> > >
> > > The problematic scenario would be something like:
> > >
> > > 1. process A opens fd1=open("/proc/self/mem",O_RDWR)
> > > 2. process A does lseek(fd1, <address of libc>, SEEK_SET)
> > > 3. A sends fd1 to privileged daemon B as a "log output" FD
> > > 4. privileged daemon B write()s into fd1
> > >
> > > In this scenario, daemon B is just trying to write log output into a
> > > file descriptor. If we checked the current credentials on write(), we
> > > might enable FOLL_FORCE just because daemon B is generally permitted
> > > to use ptrace.
> > >
> > > This illustrates why, in general, the "ambient privilege" that a
> > > process has must not influence write() access decisions.
> >
> > Ahh. That makes sense.
> >
> > But I mean in this case the check would be that the mm is the one belonging to
> > the process in question so wouldn't you need in the first place to have obtained
> > a privileged mm anyway?
> >
> > If the check is literally mm of /proc/$pid/mem == current->mm?
>
> Ah, right, true.
>
> Still, I think I want to generally avoid looking at the current
> process in write(). If I did add such a check, and the check failed,
> I'm also not sure what I'd do with this information.

True it's not a blocker!

>
> > And wouldn't prilileged process -> fd to /proc/$pid/mem -> less privileged
> > process be a fail in itself?
>
> Yes, true.

Yeah just food for thought I guess :)


--
Cheers, Lorenzo