Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Mon, Jan 23, 2017 at 9:07 PM, Andy Lutomirski [off-list ref] wrote:

On Mon, Jan 23, 2017 at 3:46 AM, Djalal Harouni [off-list ref] wrote:

quoted

On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski [off-list ref] wrote:

quoted

I agree that the kernel change to do it per task is very simple.  But
this is an unfortunate slippery slope.  What if you want to block off
everything in /proc that isn't associated with a PID?  What if you
want to suppress /sys access?  What if you want ot block *all*
non-current PIDs from being revealed in /proc?  What if you want to
hide /proc/PID/cmdline?

For /sys we mount an inaccessible directory on top, we even do that
for some static /sys and /proc inodes, of course that doesn't scale
but we try... please see below.

So you do have a private fs namespace.

Yes for some cases and they are cheap, however I don't see the relation here ?

quoted

quoted

I think that the right solution here is to fix procfs to understand
per-superblock mount options.

Unfortunately and as also noted by Lafcadio and you this is too
complex.
... but lets please stay focused here, fixing procfs is a bit out of the
scope for this *specific* use case and patch, we don't have the
resources to explore something new...

I'm not the final authority on this (that's probably Eric), but NAK.

(I don't know the final authority. The *only* thing I know is that we
have technical problems here that are *not* fixed, and we try to fix
them).

For upstream Linux, you can't say "doing it right is too hard so we're
going to introduce a hackish ABI with questionable security
properties".

No one said this.

Maybe you think that procfs is the right way, but I certainly can't
predict how much damage any fundamental change on procfs will make.
procfs is a special fs that has its own rules and hacks... everyone
would like to avoid major changes on it...

Could you please explain in clear words what are the benefits to use
mount, retain or regain CAP_SYS_ADMIN for something that we can set
without any privileges ?

The right solution is IMO quite clearly to fix /proc.  This isn't even
particularly hard -- there are only 17 instances of s_fs_info in
fs/proc/.

pid namespaces are tied to procfs to the heart, any change on procfs
has also to count on pid namespaces, flush cached entries of a task
from each /proc... ? pid namespaces have then to be made smarter.
Forward port vulnerability and bug fixes that have been stacked in
procfs ? or at least do not break them. "procfs has always been a
special fs" by git logs. Also cases of some specific directories
/proc/fs/nfs and maybe devices id  ?
persistent of mount options and other userspace information -
https://lkml.org/lkml/2012/3/26/486

These prevent me from asserting that's the best way... where in a
previous thread you said that we should go with the easiest way to fix
the problem.


-- 
tixxdz
http://opendz.org