Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754797AbbBLC3r (ORCPT ); Wed, 11 Feb 2015 21:29:47 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:6779 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753661AbbBLC3p (ORCPT ); Wed, 11 Feb 2015 21:29:45 -0500 Date: Wed, 11 Feb 2015 18:29:10 -0800 From: Calvin Owens To: Cyrill Gorcunov , "Kirill A. Shutemov" , Andrew Morton CC: Alexey Dobriyan , Oleg Nesterov , "Eric W. Biederman" , Al Viro , "Kirill A. Shutemov" , Peter Feiner , Grant Likely , Siddhesh Poyarekar , , , Pavel Emelyanov Subject: [RFC][PATCH v3] procfs: Always expose /proc//map_files/ and make it readable Message-ID: <20150212022910.GA3247638@mail.thefacebook.com> References: <1421194829-28696-1-git-send-email-calvinowens@fb.com> <20150114152501.GB9820@node.dhcp.inet.fi> <20150114153323.GF2253@moon> <20150114204653.GA26698@mail.thefacebook.com> <20150114211613.GH2253@moon> <20150122024554.GB23762@mail.thefacebook.com> <20150124031544.GA1992748@mail.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20150124031544.GA1992748@mail.thefacebook.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Originating-IP: [192.168.16.4] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-12_01:2015-02-11,2015-02-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.128698695412054 urlsuspect_oldscore=0.128698695412054 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=2524143 rbsscore=0.128698695412054 spamscore=0 recipient_to_sender_domain_totalscore=12 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502120026 X-FB-Internal: deliver Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6276 Lines: 183 Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is useful for enumerating the files mapped into a process when the more verbose information in /proc//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 removes the CAP_SYS_ADMIN restrictions. With that change alone, accessing this interface would have required PTRACE_MODE_READ like the links in /proc//fd/*. However, a discussion on lkml concluded that MODE_READ is not sufficient, both because write access to the inodes these links point to allows direct modification of a process's address space, and because it exposes files that users may have overlooked permissions on because it was assumed they would be inaccessible (either deleted as per above, or created via O_TMPFILE). So, in addition to the above, this patch enforces PTRACE_MODE_ATTACH on all the map_files/ operations. Since this is the same check that determines if access to /proc//mem is allowed, it will not allow an attacker to do anything that was not already possible through that interface. Signed-off-by: Calvin Owens --- Changes in v3: Changed permission checks to use PTRACE_MODE_ATTACH instead of PTRACE_MODE_READ, and added a stub to enforce MODE_ATTACH on follow_link() as well. Changes in v2: Removed the follow_link() stub that returned -EPERM if the caller didn't have CAP_SYS_ADMIN, since the caller in my chroot() scenario gets -EACCES anyway. fs/proc/base.c | 59 ++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 37 insertions(+), 22 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 3f3d7ae..1355a4d 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -1632,8 +1632,6 @@ end_instantiate: return dir_emit(ctx, name, len, 1, DT_UNKNOWN); } -#ifdef CONFIG_CHECKPOINT_RESTORE - /* * dname_to_vma_addr - maps a dentry name into two unsigned longs * which represent vma start and end addresses. @@ -1660,17 +1658,12 @@ static int map_files_d_revalidate(struct dentry *dentry, unsigned int flags) if (flags & LOOKUP_RCU) return -ECHILD; - if (!capable(CAP_SYS_ADMIN)) { - status = -EPERM; - goto out_notask; - } - inode = dentry->d_inode; task = get_proc_task(inode); if (!task) goto out_notask; - mm = mm_access(task, PTRACE_MODE_READ); + mm = mm_access(task, PTRACE_MODE_ATTACH); if (IS_ERR_OR_NULL(mm)) goto out; @@ -1753,6 +1746,39 @@ struct map_files_info { unsigned char name[4*sizeof(long)+2]; /* max: %lx-%lx\0 */ }; +/* + * Enforce stronger PTRACE_MODE_ATTACH permissions on the symlinks under + * /proc//map_files, since these links may refer to deleted or O_TMPFILE + * files that users might assume are inaccessible regardless of their + * ownership/permissions. + */ +static void *proc_map_files_follow_link(struct dentry *dentry, struct nameidata *nd) +{ + struct inode *inode = dentry->d_inode; + struct task_struct *task; + int allowed = 0; + + task = get_proc_task(inode); + if (task) { + allowed = ptrace_may_access(task, PTRACE_MODE_ATTACH); + put_task_struct(task); + } + + if (!allowed) + return ERR_PTR(-EACCES); + + return proc_pid_follow_link(dentry, nd); +} + +/* + * Identical to proc_pid_link_inode_operations except for follow_link() + */ +static const struct inode_operations proc_map_files_link_inode_operations = { + .readlink = proc_pid_readlink, + .follow_link = proc_map_files_follow_link, + .setattr = proc_setattr, +}; + static int proc_map_files_instantiate(struct inode *dir, struct dentry *dentry, struct task_struct *task, const void *ptr) @@ -1768,7 +1794,7 @@ proc_map_files_instantiate(struct inode *dir, struct dentry *dentry, ei = PROC_I(inode); ei->op.proc_get_link = proc_map_files_get_link; - inode->i_op = &proc_pid_link_inode_operations; + inode->i_op = &proc_map_files_link_inode_operations; inode->i_size = 64; inode->i_mode = S_IFLNK; @@ -1792,17 +1818,13 @@ static struct dentry *proc_map_files_lookup(struct inode *dir, int result; struct mm_struct *mm; - result = -EPERM; - if (!capable(CAP_SYS_ADMIN)) - goto out; - result = -ENOENT; task = get_proc_task(dir); if (!task) goto out; result = -EACCES; - if (!ptrace_may_access(task, PTRACE_MODE_READ)) + if (!ptrace_may_access(task, PTRACE_MODE_ATTACH)) goto out_put_task; result = -ENOENT; @@ -1849,17 +1871,13 @@ proc_map_files_readdir(struct file *file, struct dir_context *ctx) struct map_files_info *p; int ret; - ret = -EPERM; - if (!capable(CAP_SYS_ADMIN)) - goto out; - ret = -ENOENT; task = get_proc_task(file_inode(file)); if (!task) goto out; ret = -EACCES; - if (!ptrace_may_access(task, PTRACE_MODE_READ)) + if (!ptrace_may_access(task, PTRACE_MODE_ATTACH)) goto out_put_task; ret = 0; @@ -2040,7 +2058,6 @@ static const struct file_operations proc_timers_operations = { .llseek = seq_lseek, .release = seq_release_private, }; -#endif /* CONFIG_CHECKPOINT_RESTORE */ static int proc_pident_instantiate(struct inode *dir, struct dentry *dentry, struct task_struct *task, const void *ptr) @@ -2537,9 +2554,7 @@ static const struct inode_operations proc_task_inode_operations; static const struct pid_entry tgid_base_stuff[] = { DIR("task", S_IRUGO|S_IXUGO, proc_task_inode_operations, proc_task_operations), DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations, proc_fd_operations), -#ifdef CONFIG_CHECKPOINT_RESTORE DIR("map_files", S_IRUSR|S_IXUSR, proc_map_files_inode_operations, proc_map_files_operations), -#endif DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, proc_fdinfo_operations), DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, proc_ns_dir_operations), #ifdef CONFIG_NET -- 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/