Re: [PATCH] Allow restricting permissions in /proc/sys

[Topi Miettinen]

On 5.11.2019 1.41, Eric W. Biederman wrote:
> Topi Miettinen <toiwoton@xxxxxxxxx> writes:
>
> > On 4.11.2019 17.44, Eric W. Biederman wrote:
> > > Do you have specific examples of the cases where you would like to
> > > change the permissions?
> >
> > Unprivileged applications typically do not need to access most items
> > in /proc/sys, so I'd like to gradually find out which are needed. So
> > far I've seen no problems with 0500 mode for directories abi, crypto,
> > debug, dev, fs, user or vm.
>
> But if there is no problem in letting everyone access the information
> why reduce the permissions?

Because information could be useful to an attacker. If there is no 
problem in not letting everyone access the information why not allow 
reducing the permissions? There certainly is no need to know.

> > I'm also using systemd's InaccessiblePaths to limit access (which
> > mounts an inaccessible directory over the path), but that's a bit too
> > big hammer. For example there are over 100 files in /proc/sys/kernel,
> > perhaps there will be issues when creating a mount for each, and that
> > multiplied by a number of services.
>
> My sense is that if there is any kind of compelling reason to make
> world-readable values not world-readable, and it doesn't break anything
> (except malicious applications) than a kernel patch is probably the way
> to go.

With kernel patch, do you propose to change individual sysctls to not 
world-readable? That surely would help everybody instead of just those 
who care enough to change /proc/sys permissions. I guess it would also 
be more effort by an order of magnitude or two to convince each owner of 
a sysctl to accept the change.

> Policy knobs like this on proc tend to break in normal maintenance
> because they are not used enough so I am not a big fan of adding policy
> knobs just because we can.

But the rest of the /proc (except PID tree) allows changing permissions 
(and also UID and GID), just /proc/sys doesn't. This doesn't seem very 
logical to me.

These code paths have not changed much or at all since the initial 
version in 2007, so I suppose the maintenance burden has not been 
overwhelming.

By the way, /proc/sys still allows changing the {a,c,m}time. I think 
those are not backed anywhere, so they probably suffer from same caching 
problems as my first version of the patch.

-Topi