On Thu, Apr 25, 2024 at 08:27:05PM -0400, Kent Overstreet wrote: > On Thu, Apr 25, 2024 at 04:47:18PM -0700, Andrew Morton wrote: > > On Thu, 25 Apr 2024 15:42:30 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > > > > The concern about leaking image layout could be addressed by sorting the > > > > output before returning to userspace. > > > > > > It's trivial to change permissions from the default 0400 at boot time. > > > It can even have groups and ownership changed, etc. This is why we have > > > per-mount-namespace /proc instances: > > > > > > # chgrp sysmonitor /proc/allocinfo > > > # chmod 0440 /proc/allocinfo > > > > > > Poof, instant role-based access control. :) > > > > Conversely, the paranoid could set it to 0400 at boot also. > > > > > I'm just trying to make the _default_ safe. > > > > Agree with this. > > > > Semi-seriously, how about we set the permissions to 0000 and force > > distributors/users to make a decision. > > I'm ok with 0400 for now since it's consistent with slabinfo, but I'd > really like to see a sysctl for debug info paranoia. We shouldn't be > leaving this to the distros; we're the ones with the expertise to say > what would be covered by that sysctl. We've not had great luck with sysctls (see userns sysctl discussions) since they don't provide sufficient granularity. All this said, I'm still not excited about any of these files living in /proc at all -- we were supposed to use /sys for this kind of thing, but its interface wasn't great for this kind of more "free-form" data, and debugfs isn't good for production interfaces. /proc really should only have pid information -- we end up exposing these top-level files to every mount namespace with a /proc mount. :( But that's a yet-to-be-solved problem... -Kees -- Kees Cook
