Messages in this thread | | | Date | Mon, 29 Aug 2011 16:00:00 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v3] proc: fix races against execve() of /proc/PID/fd** |
| |
On Mon, 29 Aug 2011 22:00:11 +0400 Vasiliy Kulikov <segoon@openwall.com> wrote:
> fd* files are restricted to the task's owner, and other users may not > get direct access to them. But one may open any of these files and run > any setuid program, keeping opened file descriptors. As there are > permission checks on open(), but not on readdir() and read(), operations > on the kept file descriptors will not be checked. It makes it possible > to violate procfs permission model. > > Reading fdinfo/* may disclosure current fds' position and flags, reading > directory contents of fdinfo/ and fd/ may disclosure the number of opened > files by the target task. This information is not sensible per se, but > it can reveal some private information (like length of a password stored in > a file) under certain conditions. > > Used existing (un)lock_trace functions to check for ptrace_may_access(), > but instead of using EPERM return code from it use EACCES to be > consistent with existing proc_pid_follow_link()/proc_pid_readlink() > return code. If they differ, attacker can guess what fds exist by > analyzing stat() return code. Patched handlers: stat() for fd/*, stat() > and read() for fdindo/*, readdir() and lookup() for fd/ and fdinfo/. > > + rc = -EACCES; > + if (lock_trace(task)) > + goto out_task; > + > > ... > > + rc = -EACCES; > + if (lock_trace(task)) > + goto out_task; > + > > ... > > + result = ERR_PTR(-EACCES); > + if (lock_trace(task)) > + goto out; > + > > ... > > + > + retval = -EACCES; > + if (lock_trace(p)) > + goto out; > + > > ... >
lock_trace() can return -EPERM, and it can return whatever mutex_lock_killable() returned (-EINTR, perhaps other things?).
The patch simply overwrites this return value with -EACCES. Is this deliberate and correct? If so, please explain?
| |