FreeBSD Security Advisory FreeBSD-SA-06:25.kmem

[Robert Watson]

On Wed, 6 Dec 2006, Craig Edwards wrote:

> Doesn't securelevel completely mitigate this even for root users anyway, if 
> set? Setting securelevel denies raw access to disk devices and kmem in this 
> way does it not?

Securelevel is intended to protect integrity and not confidentiality, so does 
not prevent reading, not writing, so is unrelated to this specific issue.

I come out generally against releasing an advisory for this issue.  In the 
current security model, members of the operator group have a high level of 
privilege in the system, as they can:

- Read from partitions used for file system storage, including delete and
  unallocated space.

- Read from swap partitions, allowing access to both kernel dumps and paged
   out process data.  Since they can generally force paging on systems with
   swap, this effectively means read access to most process memory, as well as
   the pageable memory associated with kernel pipe IPC.

- Directly interface with the many controllers and other devices via device
   drivers granting read or write access to the operator group.

I think releasing a security advisory for this problem offers a false promise: 
we don't promise to protect kernel data or the kernel from the operator user, 
and releasing an advisory suggests we do.  I think it's very likely that other 
device drivers

On the other hand, I think we should be thinking about replacements for our 
current notion of an operator group.  For example, should we have 
shutdown/dump/etc be setgid operator for access to disk, but authorize use 
based on membership of another group, which would avoid granting device I/O 
privileges to members of this new operator group?  Likewise, the right to 
shutdown a system should not necessarily correspond with the right to back up 
any mounted file system.  Thoughts on the best thing to do here would be most 
welcome.

Mac OS X, for example, has a notion of a user space policy file in /etc that 
is checked by various setuid/setgid tools to see whether the invoking user has 
a specific high level privilege.  The distinction between high level and low 
level there, btw, is that a low level privilege is the privilege as 
represented with respect to the kernel (reboot, read raw disk, etc) and the 
high level privilege is the use of privilege provided and interpretted by a 
privilege-elevated (setuid/setgid) program (the right to shutdown, the right 
to back up, etc).  Obviously, the program implementing the service has to have 
significant low level privilege, but it also gates rights due to its 
interpretation of a higher level notion of privilege and authorization.

Robert N M Watson
Computer Laboratory
University of Cambridge