[PATCH 2/3] proc: query LSMs for introspective mem access (if PROC_MEM_FORCE_ALWAYS)
Jann Horn
jannh at google.com
Mon Aug 24 17:43:02 UTC 2026
On Mon, Aug 24, 2026 at 7:33 PM Lorenzo Stoakes (ARM) <ljs at kernel.org> 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) <ljs at kernel.org> 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.
> 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.
More information about the Linux-security-module-archive
mailing list