From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux Security Module <linux-security-module@vger.kernel.org>,
Akinobu Mita <akinobu.mita@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Alexey Dobriyan <adobriyan@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Djalal Harouni <tixxdz@gmail.com>,
"Dmitry V . Levin" <ldv@altlinux.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@kernel.org>,
"J . Bruce Fields" <bfields@fieldses.org>,
Jeff Layton <jlayton@poochiereds.net>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromium.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH RESEND v11 2/8] proc: allow to mount many instances of proc in one pid namespace
Date: Sun, 19 Apr 2020 16:17:27 +0200 [thread overview]
Message-ID: <20200419141727.zjstym5kbp5efoz6@comp-core-i7-2640m-0182e6> (raw)
In-Reply-To: <87tv1iaqnq.fsf@x220.int.ebiederm.org>
On Fri, Apr 17, 2020 at 01:55:05PM -0500, Eric W. Biederman wrote:
> Alexey Gladkov <gladkov.alexey@gmail.com> writes:
>
> > This patch allows to have multiple procfs instances inside the
> > same pid namespace. The aim here is lightweight sandboxes, and to allow
> > that we have to modernize procfs internals.
> >
> > 1) The main aim of this work is to have on embedded systems one
> > supervisor for apps. Right now we have some lightweight sandbox support,
> > however if we create pid namespacess we have to manages all the
> > processes inside too, where our goal is to be able to run a bunch of
> > apps each one inside its own mount namespace without being able to
> > notice each other. We only want to use mount namespaces, and we want
> > procfs to behave more like a real mount point.
> >
> > 2) Linux Security Modules have multiple ptrace paths inside some
> > subsystems, however inside procfs, the implementation does not guarantee
> > that the ptrace() check which triggers the security_ptrace_check() hook
> > will always run. We have the 'hidepid' mount option that can be used to
> > force the ptrace_may_access() check inside has_pid_permissions() to run.
> > The problem is that 'hidepid' is per pid namespace and not attached to
> > the mount point, any remount or modification of 'hidepid' will propagate
> > to all other procfs mounts.
> >
> > This also does not allow to support Yama LSM easily in desktop and user
> > sessions. Yama ptrace scope which restricts ptrace and some other
> > syscalls to be allowed only on inferiors, can be updated to have a
> > per-task context, where the context will be inherited during fork(),
> > clone() and preserved across execve(). If we support multiple private
> > procfs instances, then we may force the ptrace_may_access() on
> > /proc/<pids>/ to always run inside that new procfs instances. This will
> > allow to specifiy on user sessions if we should populate procfs with
> > pids that the user can ptrace or not.
> >
> > By using Yama ptrace scope, some restricted users will only be able to see
> > inferiors inside /proc, they won't even be able to see their other
> > processes. Some software like Chromium, Firefox's crash handler, Wine
> > and others are already using Yama to restrict which processes can be
> > ptracable. With this change this will give the possibility to restrict
> > /proc/<pids>/ but more importantly this will give desktop users a
> > generic and usuable way to specifiy which users should see all processes
> > and which users can not.
> >
> > Side notes:
> > * This covers the lack of seccomp where it is not able to parse
> > arguments, it is easy to install a seccomp filter on direct syscalls
> > that operate on pids, however /proc/<pid>/ is a Linux ABI using
> > filesystem syscalls. With this change LSMs should be able to analyze
> > open/read/write/close...
> >
> > In the new patchset version I removed the 'newinstance' option
> > as suggested by Eric W. Biederman.
>
> Some very small requests.
>
> 1) Can you please not place fs_info in fs_context, and instead allocate
> fs_info in fill_super? Unless I have misread introduced a resource
> leak if proc is not mounted or if proc is simply reconfigured.
Hm ... it seems you're right.
> 2) Can you please move hide_pid and pid_gid into fs_info in this patch?
> As was shown by my recent bug fix
OK. I’ll do it in the next version.
> 3) Can you please rebase on on v5.7-rc1 or v5.7-rc2 and repost these
> patches please? I thought I could do it safely but between my bug
> fixes, and Alexey Dobriyan's parallel changes to proc these patches
> do not apply cleanly.
>
> Plus there is a resource leak in this patch.
On my way.
> > struct proc_fs_context {
> > - struct pid_namespace *pid_ns;
> > + struct proc_fs_info *fs_info;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Please don't do this. As best as I can tell that introduces a memory
> leak of proc is not mounted. Please allocate fs_info in
OK.
--
Rgrds, legion
next prev parent reply other threads:[~2020-04-19 14:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 12:37 [PATCH RESEND v11 0/8] proc: modernize proc to support multiple private instances Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 1/8] proc: rename struct proc_fs_info to proc_fs_opts Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 2/8] proc: allow to mount many instances of proc in one pid namespace Alexey Gladkov
2020-04-17 18:55 ` Eric W. Biederman
2020-04-19 14:17 ` Alexey Gladkov [this message]
2020-04-09 12:37 ` [PATCH RESEND v11 3/8] proc: move hide_pid, pid_gid from pid_namespace to proc_fs_info Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 4/8] proc: instantiate only pids that we can ptrace on 'hidepid=4' mount option Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 5/8] proc: add option to mount only a pids subset Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 6/8] docs: proc: add documentation for "hidepid=4" and "subset=pid" options and new mount behavior Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 7/8] proc: use human-readable values for hidepid Alexey Gladkov
2020-04-17 19:05 ` Eric W. Biederman
2020-04-19 14:19 ` Alexey Gladkov
2020-04-09 12:37 ` [PATCH RESEND v11 8/8] proc: use named enums for better readability Alexey Gladkov
2020-04-09 12:59 ` [PATCH RESEND v11 0/8] proc: modernize proc to support multiple private instances Eric W. Biederman
2020-04-09 13:42 ` Alexey Gladkov
2020-04-09 14:13 ` Eric W. Biederman
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=20200419141727.zjstym5kbp5efoz6@comp-core-i7-2640m-0182e6 \
--to=gladkov.alexey@gmail.com \
--cc=adobriyan@gmail.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=corbet@lwn.net \
--cc=danielmicay@gmail.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jlayton@poochiereds.net \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=ldv@altlinux.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=tixxdz@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).