Security: information leaks in /proc enable keystroke recovery

[Robert Watson]

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