Date: Sun, 28 Apr 2002 22:31:34 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: cjclark@alum.mit.edu Cc: Richard Arends <richard@unixguru.nl>, Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.org Subject: Re: truss Message-ID: <Pine.NEB.3.96L.1020428222306.64976R-100000@fledge.watson.org> In-Reply-To: <20020428163257.K37618@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Apr 2002, Crist J. Clark wrote: > > Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was > > probably thinking of top, which still is setgid in -STABLE. You'll find > > however, that -e won't work without setgid kmem being turned on. > > '-e' for ps(1) seems to work fine on processes you own. You cannot see > the environments of other users' processes (of course root can see > everyone's). But you do need /proc for '-e' to work. There might be other criteria where you wish to protect environmental information, such as for setugid processes, in jail, etc. Having the policy in kernel means that you can change it in one place, rather that tracking through various user space programs (which may not even have all the information they need). > > There > > are a number of other tools in -CURRENT that aren't setgid kmem where they > > are in -STABLE (top, iostat, etc). > > You know, I'm not sure why top(1) needs it if ps(1) doesn't. My recollection is that Thomas Moestl had to add a number of sysctl's to return system information that top previously pulled out of /dev/kmem. There are two related campaigns here: (1) Eliminate the requirements for procfs due to the risks involved There have been a large number of serious vulnerabilities due to the procfs concept a number of operating systems. A high percentage of our local anyone-to-root vulnerabilities have come from procfs. This combined with a largely redundant feature set lead to the conclusion that we should try and phase out the requirement that it be mounted, since a common hardening technique is to unmount it. (2) Eliminate the requirements for kmem due to the risks involved As with procfs, there have been a number of vulnerabilities associated with kmem, and as with procfs, when a vulnerability is present, the level of privilege that can be attained is high -- usually root with a little bit of work. Eiminating the use of kmem and replacing it with better defined sysctl APIs also means that the tight userland/kernel dependencies that used to result in failures during upgrades could be partially eliminated. Likewise, policy implemented in userspace could be further migrated to kernel space (limiting netstat socket display, process listings, etc). In both cases, the actual services themselves are not being eliminated, since they have uses (especially kmem) in some restricted environments (such as development), but the general requirement that they be used for common place activities is being reduced. A number of utilities still use kmem, and if anyone wants to pick up the task of converting them over the sysctl or other mechanisms, they should feel free :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020428222306.64976R-100000>