Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Apr 2018 20:45:09 +0300
From:   Alexey Dobriyan <adobriyan@gmail.com>
To:     alban@kinvolk.io
Cc:     linux-kernel@vger.kernel.org, ebiederm@xmission.com
Subject: Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc
 mounts when not fully visible
Message-ID: <20180404174509.GA2540@avx2>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.7.2 (2016-11-26)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Instead, it introduces new options in proc to disable some proc entries (TBD).

No, no, no, no.

Blacklists are bad, mmkay.

The reason is that quite dangerous new /proc entries get added
(think /proc/kpageflags) and suddenly they are enabled inside container.

> The granularity does not need to be per proc entry.

I think it does. Grouping always becomes either too fine or too coarse.

> Granularity can be improved later if use cases exist.

Granularity can not be tightened as it may break existing users.
So new granularity options are going to be invented until finally it is
per file.

>	"maskedPaths": [
>		"/proc/kcore",
>		"/proc/latency_stats",
>		"/proc/timer_list",
>		"/proc/timer_stats",
>		"/proc/sched_debug",
>		"/sys/firmware",
>		"/proc/scsi"
>	],

Just say no to drugs.


> /proc/kcore

As a side note:
/proc/kcore should be more or less safe because it is under CAP_SYS_RAWIO.