Date: Wed, 24 Nov 1999 08:22:53 -0800 (PST) From: David Wolfskill <dhw@whistle.com> To: security@FreeBSD.ORG Subject: Re: ps on 4.0-current Message-ID: <199911241622.IAA25297@pau-amma.whistle.com> In-Reply-To: <19991124090523.9689C1C6D@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Wed, 24 Nov 1999 17:05:23 +0800
>From: Peter Wemm <peter@netplex.com.au>
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911241622.IAA25297>