From: Vasiliy Kulikov <segoon@openwall.com>
To: kernel-hardening@lists.openwall.com,
Andrew Morton <akpm@linux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH 1/2] proc: force dcache drop on unauthorized access
Date: Sat, 10 Sep 2011 20:40:01 +0400 [thread overview]
Message-ID: <20110910164001.GA2342@albatros> (raw)
The patch "proc: fix races against execve() of /proc/PID/fd**" is still
a partial fix for a setxid problem. link(2) is a yet another way to
identify whether a specific fd is opened by a privileged process. By
calling link(2) against /proc/PID/fd/* an attacker may identify whether
the fd number is valid for PID by analysing link(2) return code.
Both getattr() and link() can be used by the attacker iff the dentry is
present in the dcache. In this case ->lookup() is not called and the
only way to check ptrace permissions is either operation handler or
->revalidate(). The easiest solution to prevent any unauthorized access
to /proc/PID/fd*/ files is to force the dentry drop on each unauthorized
access attempt.
If an attacker keeps opened fd of /proc/PID/fd/ and dcache contains
a specific dentry for some /proc/PID/fd/XXX, any future attemp to use the
dentry by the attacker would lead to the dentry drop as a result of a
failed ptrace check in ->revalidate(). Then the attacker cannot spawn a
dentry for the specific fd number because of ptrace check in ->lookup().
The dentry drop can be still observed by an attacker by analysing
information from /proc/slabinfo, which is addressed in the successive
patch.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
fs/proc/base.c | 42 ++++++------------------------------------
1 files changed, 6 insertions(+), 36 deletions(-)
--
diff --git a/fs/proc/base.c b/fs/proc/base.c
index d44c701..8b72293 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1665,46 +1665,12 @@ out:
return error;
}
-static int proc_pid_fd_link_getattr(struct vfsmount *mnt, struct dentry *dentry,
- struct kstat *stat)
-{
- struct inode *inode = dentry->d_inode;
- struct task_struct *task = get_proc_task(inode);
- int rc;
-
- if (task == NULL)
- return -ESRCH;
-
- rc = -EACCES;
- if (lock_trace(task))
- goto out_task;
-
- generic_fillattr(inode, stat);
- unlock_trace(task);
- rc = 0;
-out_task:
- put_task_struct(task);
- return rc;
-}
-
static const struct inode_operations proc_pid_link_inode_operations = {
.readlink = proc_pid_readlink,
.follow_link = proc_pid_follow_link,
.setattr = proc_setattr,
};
-static const struct inode_operations proc_fdinfo_link_inode_operations = {
- .setattr = proc_setattr,
- .getattr = proc_pid_fd_link_getattr,
-};
-
-static const struct inode_operations proc_fd_link_inode_operations = {
- .readlink = proc_pid_readlink,
- .follow_link = proc_pid_follow_link,
- .setattr = proc_setattr,
- .getattr = proc_pid_fd_link_getattr,
-};
-
/* building an inode */
@@ -2013,6 +1979,11 @@ static int tid_fd_revalidate(struct dentry *dentry, struct nameidata *nd)
task = get_proc_task(inode);
fd = proc_fd(inode);
+ if (!ptrace_may_access(task, PTRACE_MODE_READ)) {
+ put_task_struct(task);
+ task = NULL;
+ }
+
if (task) {
files = get_files_struct(task);
if (files) {
@@ -2085,7 +2056,7 @@ static struct dentry *proc_fd_instantiate(struct inode *dir,
spin_unlock(&files->file_lock);
put_files_struct(files);
- inode->i_op = &proc_fd_link_inode_operations;
+ inode->i_op = &proc_pid_link_inode_operations;
inode->i_size = 64;
ei->op.proc_get_link = proc_fd_link;
d_set_d_op(dentry, &tid_fd_dentry_operations);
@@ -2267,7 +2238,6 @@ static struct dentry *proc_fdinfo_instantiate(struct inode *dir,
ei->fd = fd;
inode->i_mode = S_IFREG | S_IRUSR;
inode->i_fop = &proc_fdinfo_file_operations;
- inode->i_op = &proc_fdinfo_link_inode_operations;
d_set_d_op(dentry, &tid_fd_dentry_operations);
d_add(dentry, inode);
/* Close the race of the process dying before we return the dentry */
next reply other threads:[~2011-09-10 16:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 16:40 Vasiliy Kulikov [this message]
2011-09-10 16:41 ` [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo Vasiliy Kulikov
2011-09-12 15:06 ` Cyrill Gorcunov
2011-09-13 6:28 ` Vasiliy Kulikov
2011-09-14 13:16 ` Vasiliy Kulikov
2011-09-14 15:18 ` Dave Hansen
2011-09-14 15:42 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-14 15:48 ` Vasiliy Kulikov
2011-09-14 18:24 ` Dave Hansen
2011-09-14 18:41 ` Dave Hansen
2011-09-14 19:14 ` Vasiliy Kulikov
2011-09-14 19:27 ` Kees Cook
2011-09-18 17:05 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-19 13:42 ` Christoph Lameter
2011-09-19 14:30 ` Pekka Enberg
2011-09-19 14:46 ` Vasiliy Kulikov
2011-09-19 15:13 ` Pekka Enberg
2011-09-19 15:57 ` Vasiliy Kulikov
2011-09-19 16:11 ` Pekka Enberg
2011-09-19 16:18 ` Vasiliy Kulikov
2011-09-19 17:31 ` Pekka Enberg
2011-09-19 17:35 ` Vasiliy Kulikov
2011-09-19 17:51 ` Christoph Lameter
2011-09-19 19:59 ` Valdis.Kletnieks
2011-09-19 20:02 ` Christoph Lameter
2011-09-19 20:36 ` Valdis.Kletnieks
2011-09-19 17:51 ` Pekka Enberg
2011-09-19 17:58 ` Vasiliy Kulikov
2011-09-19 18:46 ` Pekka Enberg
2011-09-19 18:55 ` Vasiliy Kulikov
2011-09-19 19:20 ` Pekka Enberg
2011-09-19 19:33 ` Pekka Enberg
2011-09-19 18:55 ` Linus Torvalds
2011-09-19 19:18 ` Pekka Enberg
2011-09-19 19:45 ` Pekka Enberg
2011-09-19 20:59 ` David Rientjes
2011-09-19 18:03 ` Dave Hansen
2011-09-19 18:21 ` Pekka Enberg
2011-09-19 19:45 ` Valdis.Kletnieks
2011-09-19 19:55 ` Alan Cox
2011-09-21 17:05 ` Vasiliy Kulikov
2011-09-22 2:20 ` Valdis.Kletnieks
2011-09-22 17:57 ` [RFC PATCH 1/2] proc: force dcache drop on unauthorized access Vasiliy Kulikov
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=20110910164001.GA2342@albatros \
--to=segoon@openwall.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=gorcunov@gmail.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.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