linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lafcadio Wluiki <wluikil@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Djalal Harouni <tixxdz@gmail.com>,
	Linux API <linux-api@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field
Date: Fri, 10 Feb 2017 15:40:47 +0100	[thread overview]
Message-ID: <CAOWbf6f-3Ha3dkNuTfar0-u1SdSu=gDt0tK3Wq9+f9LZqB4gMQ@mail.gmail.com> (raw)
In-Reply-To: <CALCETrX_K7XdyCRo1RSLySRu-2uySaR2+3J7qcw4O+JOepTwag@mail.gmail.com>

On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski <luto@amacapital.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?

These are all what-ifs that noone was interested in so far. I have a
very specific itch I want to scratch, and I found a reasonably generic
concept of exposing it. But now you are trying to lead this all down
onto a paths asking for features noone is actually really interested
in.

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

Andy, this is really not helpful. Doing that is far from easy, that's
a major undertaking: asking us to rework procfs in such a major way I
only can understand as an indirect way for you to say "go away" to
us... Expecting newcomers to kernel work to basically clean up an
entire kernel subsystem, dealing with all the politics involved is
just not going to work.

And again: I am very sure the proposed prctl() based solution is
actually much much nicer than any procfs superblock based one, since
it works naturally, and easily for unprivileged processes too!
Anything that requires mount options means privileges are required in
some form or another. Yes userns would open that up, but that comes
with a huge amount of additional problems.

Anyway, I understand it is your intention to derail this. I can accept
that. It's a pity though.

L.

  parent reply	other threads:[~2017-02-10 14:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 13:23 [PATCH v4 0/2] procfs/tasks: introduce per-task procfs hidepid= field Djalal Harouni
2017-01-16 13:23 ` [PATCH v4 1/2] procfs: use an enum for possible hidepid values Djalal Harouni
2017-02-13 22:16   ` Kees Cook
2017-02-15  0:34     ` Andrew Morton
2017-02-15  8:56       ` Djalal Harouni
2017-01-16 13:23 ` [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field Djalal Harouni
2017-01-16 18:24   ` [kernel-hardening] " Daniel Micay
2017-01-17  9:54     ` Lafcadio Wluiki
     [not found]   ` <CAEiveUfDvSoW9Hy2Y_uxU2YQ+vR8OvXMqRhxAANTGG7QaQbJeg@mail.gmail.com>
     [not found]     ` <CALCETrWEGLhEHO_6sTXreVyWFVsEeYmZSrLNNXx-ma5gd+nTQQ@mail.gmail.com>
2017-01-18 22:50       ` Djalal Harouni
2017-01-18 23:35         ` Andy Lutomirski
2017-01-19 13:53           ` Djalal Harouni
2017-01-19 19:52             ` Andy Lutomirski
2017-01-20 15:56               ` Lafcadio Wluiki
2017-01-20 16:33               ` Djalal Harouni
2017-01-21  0:53                 ` Andy Lutomirski
2017-01-23 11:46                   ` Djalal Harouni
2017-01-23 20:07                     ` Andy Lutomirski
2017-01-26 13:20                       ` Djalal Harouni
2017-02-10 14:40                   ` Lafcadio Wluiki [this message]
2017-02-10 16:18                     ` Andy Lutomirski
2017-01-20 15:44           ` Lafcadio Wluiki
2017-02-10 23:44           ` Kees Cook
2017-02-13 19:01             ` Andy Lutomirski
2017-02-13 19:15               ` Kees Cook
2017-02-14  4:11                 ` Christian Kujau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOWbf6f-3Ha3dkNuTfar0-u1SdSu=gDt0tK3Wq9+f9LZqB4gMQ@mail.gmail.com' \
    --to=wluikil@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tixxdz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).