From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 16 20:06:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD36106568B for ; Sun, 16 Aug 2009 20:06:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8B68FC43 for ; Sun, 16 Aug 2009 20:06:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C887C46B2A; Sun, 16 Aug 2009 16:06:41 -0400 (EDT) Date: Sun, 16 Aug 2009 21:06:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oliver Pinter In-Reply-To: <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> Message-ID: References: <200908152221.n7FMLRuw005799@taverner.cs.berkeley.edu> <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1749418058-1250453201=:1901" Cc: freebsd-hackers@freebsd.org, linux-kernel@vger.kernel.org, David Wagner Subject: Re: Security: information leaks in /proc enable keystroke recovery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 20:06:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1749418058-1250453201=:1901 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 16 Aug 2009, Oliver Pinter wrote: > FreeBSD manages its process files more cautiously than Linux12 : it puts all > register values into the file /proc/pid/regs that can only be read by the > owner of a process, which blocks the information used by This is inaccurate, but largely in an academic sense. The FreeBSD kernels computes debug permissions between two processes from a number of factors, including: - Comparison of uids (effective, real, saved) - Comparison of gids (effective, real, saved) - Subset check on the additional group set - Jail information - Mandatory access control policies There are some other checks that fit the pattern of credential comparison less well: - We deny debugger activity during execve(2) as a robustness protection against possible race conditions. - We have global policy controls, security.bsd.see_other_gids and security.bsd.see_other_uids, which allow administrators to scope not just debugging facilities, but also monitoring facilities. - We have a global policy control, security.bsd.unprivileged_proc_debug, to disable debugging facilities for unprivileged users, on the grounds that (a) this is sometimes a desirable system policy, and (b) all UNIX systems have historically suffered from significant debugger security vulnerabilities and this provides an easy work-around to use if that happens in the future. Which is to say: the UNIX file system permissions appearing in procfs are purely decorative -- they roughly summarize, but do not implement, the above checks. procfs is also deprecated in FreeBSD, and has not been mounted by default for several major releases. Instead, the system call interfaces ktrace(2), ptrace(2), and sysctl(2) provide access to trace data, process debugging, and process state (such as address space layout and file descriptor information). Some legacy setgid kvm tools exist that use libkvm and /dev/kmem, but we are eliminating these as quickly as we can; they may not follow the same policies as those implemented in the kernel. The see_other_uids and see_other_gids policy sysctls narrow the policy on inter-process visibility via monitoring controls -- however, additional hardening is required to enforce this policy universally. For example, administrators will also need to limit access to logs, accounting data, and so on, for this to be fully effective. Beyond this, and assuming the correct implementation of the above, we're into the grounds of classic trusted OS covert channel analysis, against which no COTS UNIX OSes I'm aware of are hardened. This isn't to dismiss these attacks as purely hypothetical -- we've seen some rather compelling examples of covert channels being exploited in unexpected and remarkably practical ways in the last few years (Steven Murdoch's "Hot or Not" paper takes the cake in that regard, I think). However, this next step up from "the kernel doesn't reveal information on processes from other users" involves scheduler hardening, consideration of inter-CPU/core/thread cache interactions, and so on -- things that we don't have a good research, let alone production, OS understanding of. There are tools in FreeBSD that can help with some of these issues -- for example, you can use login classes to pin different users to different CPU threads, cores, or packages. However, this leaves the implementation of policy up to the administrator, rather than simply allowing the administator to specify the policy that mutually untrusting processes can't share CPUs with each other in some window. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1749418058-1250453201=:1901--