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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
