Date: Mon, 11 Dec 2006 19:53:08 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Craig Edwards <brain@winbot.co.uk> Cc: Dan Lukes <dan@obluda.cz>, freebsd-security@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem Message-ID: <20061211193712.U4227@fledge.watson.org> In-Reply-To: <4577076A.6080508@winbot.co.uk> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <4576F3A9.9000307@obluda.cz> <4577076A.6080508@winbot.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061211193712.U4227>