Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v12

On Wed, Sep 14, 2011 at 20:13 +0400, Pavel Emelyanov wrote:

quoted

No, I mean something else.  Assume you have a task, which does the
steps:

1) opens some sensitive file as root.  This file is e.g. 0700.

2) mmaps the file via opened fd, either RO or RW.

3) closes fd.

4) drops root.

Now it has a mapping of a privileged file, but cannot get fd of it
anyhow.  With map_files/ he may open his own /proc/$$/map_files/, pass
ptrace() check, and get fd of the privileged file.  He cannot explicitly
open it as it is 0700, but he may open it via map_files/ and get RO/RW
fd.

What is the problem here - the fact that we have some file considered to
be private be open-able by somebody else, or the fact that we can truncate
the file being mapped?

The latter - the file, which is considered to be restricted to a process
as W only without ability to truncate it, now can be truncated.  The
process after (4) had no such ability without map_files/ with current
permission model of mmap'ed files.  Or I am missing something?

FWIW, ftruncate() might be not the only syscall which makes sense to use
in this case, I just thought about it.

Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments