[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jan 2017 12:07:23 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Djalal Harouni <tixxdz@...il.com>
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 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.
>
>> 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.
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".
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/.
> ... Easy to review and maintain.
Au contraire. It's a pain in the arse to review because of the
security implications and it's unpleasant to maintain because it's a
special case in core kernel code.
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.
