From owner-freebsd-security Sat Aug 22 06:04:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA28036 for freebsd-security-outgoing; Sat, 22 Aug 1998 06:04:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA28029 for ; Sat, 22 Aug 1998 06:04:22 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA00551; Sat, 22 Aug 1998 09:03:36 -0400 (EDT) Date: Sat, 22 Aug 1998 09:03:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: ben@efn.org cc: security@FreeBSD.ORG Subject: Re: libkvm and user-info tools patches (was ps(1)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems like a preferred method of attack here might be through /procfs. That is, taking this opportunity to strip the kvm-walking code from these and other utilities, and adding access control in a kernel-mediated security mechanism, as opposed to relying on the security of setuid binaries checking sysctl entries? This, of course, has been discussed a number of times. The steps would include adding any last required features to procfs, exposing a little more information in sysctl, etc. Restricting access to utmp information, however, doesn't seem as useful to me. The cost of restricting read access would probably be adding a new uid (or such), making w/etc suid to that uid and so on. Yet another uid equivilent to root on most systems. On Sat, 22 Aug 1998, Ben wrote: > A few weeks ago I released a patch to make ps -a 'break' for normal user's > preventing them from seeing other people that are logged in, and what they > are doing. I finshed those patches for w, who and top too. After taking > a look at libkvm I've decided it would be easier if kvm_getprocs was > controlled by a sysctl oid(kern.usersecure). This would prevent user's > from using it in any program that called it, by checking if kern.usersecure > was a certian number, much like securelevel is now. Take a look at what I > came up with and give me some feedback. I've been using it for 3 days now > with no problems at all. > > Text info on it: > http://www.efn.org/~ben/security/README.txt > The tarball of source diff's (diff -c against 2.2.7 stable): > http://www.efn.org/~ben/security/kvm.tgz > > -ben@efn.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message