Re: [RFC][PATCH v2] procfs: Always expose /proc/<pid>/map_files/ and make it readable

On Mon, Jan 26, 2015 at 11:37 PM, Cyrill Gorcunov [off-list ref] wrote:

On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote:

quoted

quoted

akpm3:/usr/src/25> grep -r map_files Documentation

If akpm's comments weren't clear: this needs to be fixed. Everything
in /proc should appear in Documentation.

I'll do that.

quoted

quoted

The 640708a2cff7f81 changelog says:

:     This one behaves similarly to the /proc/<pid>/fd/ one - it contains
:     symlinks one for each mapping with file, the name of a symlink is
:     "vma->vm_start-vma->vm_end", the target is the file.  Opening a symlink
:     results in a file that point exactly to the same inode as them vma's one.
:
:     For example the ls -l of some arbitrary /proc/<pid>/map_files/
:
:      | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 -> /lib64/libc-2.5.so
:      | lr-x------ 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f80620000 -> /lib64/libselinux.so.1
:      | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 -> /lib64/libacl.so.1.1.0
:      | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a30000 -> /lib64/librt-2.5.so
:      | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80a30000-7f8f80a4c000 -> /lib64/ld-2.5.so

How is mmap offset represented in this output?

We're printing vm_area_struct:[vm_start;vm_end] only.

quoted

quoted

afacit this info is also available in /proc/pid/maps, so things
shouldn't get worse if the /proc/pid/map_files permissions are at least
as restrictive as the /proc/pid/maps permissions.  Is that the case?
(Please add to changelog).

Both maps and map_files uses ptrace_may_access (via mm_acces) with
PTRACE_MODE_READ, so I'm happy from a info leak perspective.

Are mount namespaces handled in this output?

Could you clarify this moment, i'm not sure i get it.

I changed how I asked this question in my review of the documentation,
but it looks like these symlinks aren't "regular" symlinks (that are
up to the follower to have access to the file system path shown), but
rather they bypass VFS. As a result, I'm wondering how things like
mount namespaces might change this behavior: what is shown, the path
from the perspective of the target, or from the viewer (which may be
in separate mount namespaces).

-Kees

quoted

quoted

There's one other problem here: we're assuming that the map_files
implementation doesn't have bugs.  If it does have bugs then relaxing
permissions like this will create new vulnerabilities.  And the
map_files implementation is surprisingly complex.  Is it bug-free?

-- 
Kees Cook
Chrome OS Security