linux-kernel - Re: [PATCH v5] procfs: Always expose /proc/<pid>/map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrXoidupgs+DyzJ4ibS9jmvNOn4DerVvtDgck1xk_2eaFw@mail.gmail.com>
Date:	Tue, 19 May 2015 11:04:37 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Calvin Owens <calvinowens@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	Zefan Li <lizefan@...wei.com>, Oleg Nesterov <oleg@...hat.com>,
	Joe Perches <joe@...ches.com>,
	David Howells <dhowells@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kernel-team@...com, Kees Cook <keescook@...omium.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH v5] procfs: Always expose /proc/<pid>/map_files/ and make
 it readable

On Mon, May 18, 2015 at 8:10 PM, Calvin Owens <calvinowens@...com> wrote:
> Currently, /proc/<pid>/map_files/ is restricted to CAP_SYS_ADMIN, and
> is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is
> very useful for enumerating the files mapped into a process when the
> more verbose information in /proc/<pid>/maps is not needed. It also
> allows access to file descriptors for files that have been deleted and
> closed but are still mmapped into a process, which can be very useful
> for introspection and debugging.
>
> This patch moves the folder out from behind CHECKPOINT_RESTORE, and

I'm fine with this.

> removes the CAP_SYS_ADMIN restrictions. With that change alone,
> following the links would have required PTRACE_MODE_READ like the
> links in /proc/<pid>/fd/*.

I'm still not at all convinced that this is safe.  Here are a few ways
that it could have unintended consequences:

1. Mmap a dma-buf and then open /proc/self/map_files/addr.  You get an
fd pointing at a different inode than you mapped.  (kdbus would have
the same problem if it were merged.)

2. Open a file with O_RDONLY, mmap it with PROT_READ, close the file,
then open /proc/self/map_files/addr with O_RDWR.  I don't see anything
preventing that from succeeding.

3. Open a file, mmap it, close the fd, chroot, drop privileges, open
/proc/self/map_files/addr, then call ftruncate.

So NAK as-is, I think.

Fixing #1 would involve changing the way mmap works, I think.  Fixing
#2 would require similar infrastructure to what we'd need to fix the
existing /proc/pid/fd mode holes.  I have no clue how to even approach
fixing #3.

What's the use case of this patch?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/