From owner-freebsd-security Wed Nov 24 8:23:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id AC1DD14FB9 for ; Wed, 24 Nov 1999 08:23:14 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA25297 for security@FreeBSD.ORG; Wed, 24 Nov 1999 08:22:53 -0800 (PST) Date: Wed, 24 Nov 1999 08:22:53 -0800 (PST) From: David Wolfskill Message-Id: <199911241622.IAA25297@pau-amma.whistle.com> To: security@FreeBSD.ORG Subject: Re: ps on 4.0-current In-Reply-To: <19991124090523.9689C1C6D@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Date: Wed, 24 Nov 1999 17:05:23 +0800 >From: Peter Wemm [Redirected only to -security, from -security & -current. dhw] >For example, in "workstation" mode, the reasonable default is "open", >because typically there is one user on the box (other than root) and that >person has root access.... >In a dedicated server role, again it might be appropriate to default it to >"open" (dedicated server being something like a squid box), again there will be >a couple of sysadmin type users or people who have to monitor things. Hiding >information gains nothing there either. Right, though I'd think that encouraging folks to address the matter of "services not offered" on the box in question would be A Good Thing. For example, our news server doesn't provide SMTP services. And my home NAT/firewall box rejects AUTH requests, accepts things I want it to, and drops everything else on the floor (to time out whenever). (Of course, I'd expect more experienced admins to tend toward this model anyway. But less experienced ones can often use a bit of guidance. Unfortunately, the less-experienced folk can be overwhelmed by the magnitude of text telling them how to do things....) >In other roles, including something like a shell server box with presumably >hostile users (you reasonably have to assume this), you want everything you >possibly can to be locked down. And *then* some! >Oh for ACL's, privilige attributes, etc. It would solve this sort of thing >nicely so that you could allow admin users to see what's going on >(including a ps -ax and see what the users are running) without having to >constantly (ab)use root and the dangers of overusing that. True, though it would seem that allowing certain capabilities based on membership in some (set of) group(s) could help just enough to get by -- that is, so that the lack of the ACLs &c. never gets quite so painful that someone gets around to writing code to fix it. :-{ Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message