[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Jan 2017 14:20:12 +0100
From: Djalal Harouni <tixxdz@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Linux API <linux-api@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>, Lafcadio Wluiki <wluikil@...il.com>
Subject: 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 <luto@...capital.net> wrote:
> On Mon, Jan 23, 2017 at 3:46 AM, Djalal Harouni <tixxdz@...il.com> wrote:
>> On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>> 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 ?
>>
>>> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
