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
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
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message