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
