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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux