From owner-freebsd-security Wed Mar 27 10:36:12 2002 Delivered-To: freebsd-security@freebsd.org Received: from bilver.wjv.com (spdsl-033.wanlogistics.net [63.209.115.33]) by hub.freebsd.org (Postfix) with ESMTP id AE04037B405 for ; Wed, 27 Mar 2002 10:35:57 -0800 (PST) Received: (from bv@localhost) by bilver.wjv.com (8.11.6/8.11.6) id g2RIZnf33310; Wed, 27 Mar 2002 13:35:49 -0500 (EST) (envelope-from bv) Date: Wed, 27 Mar 2002 13:35:48 -0500 From: Bill Vermillion To: Tom Rhodes Cc: freebsd-security@freebsd.org Subject: Re: Question on su / possible hole Message-ID: <20020327183548.GI30556@wjv.com> Reply-To: bv@wjv.com References: <20020327140006.GA30556@wjv.com> <20020327110616.58e6ead1.darklogik@pittgoth.com> <20020327180713.GF30556@wjv.com> <20020327133238.48e32908.darklogik@pittgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020327133238.48e32908.darklogik@pittgoth.com> User-Agent: Mutt/1.3.25i Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Mar 27, 2002 at 01:32:38PM -0500, Tom Rhodes thus spoke: > On Wed, 27 Mar 2002 13:07:13 -0500 > Bill Vermillion wrote: > > > On Wed, Mar 27, 2002 at 11:06:16AM -0500, Tom Rhodes thus spoke: > > > On Wed, 27 Mar 2002 09:00:06 -0500 > > > Bill Vermillion wrote: > > > > > > > I don't know if this is where I should ask, so apologies if it's > > > > the wrong place. > > > > > What I do with my server, users that are in the wheel group MUST > > > use ssh(1) v2 key authentication. If you read the ssh > > > documentation, there is a way you can restrict access to IP > > > address also. You may wish to investigate the use of ssh(1) for > > > your system ;) > > Well I do use ssh and that is the only access other than for some > > who are locked into their own ftp area. > > But if a user comes in with ssh he can still su to a wheel user if > > he figures out their password, and then su to root even if the > > wheel group user use SSH to get in. > > So even if you restrict by IP the users who have wheel access, what > > is to prevent someone who is not in that group from SUing to one > > who is. > > That was the point I was trying to make. > > Someone else pointed out that I could make a group that could su > > to root and take off the other permssion on su - but that takes > > away the other functionality of su - many think it only means > > super user - and not substitute user - so you can assume the > > indentity and environment of another. > I'm sorry, I thought you wanted to know WHO the user is that is trying > to access su(1). My mistake hehe. Well, couldn't you remove the > remove use of root completely? And only do administrative tasks > locally? Or are you not around the box enough. Paranoia is good, > but over paranoia can lead to health problems ;) What I'm tyring to get across is that perhaps the funtionality of su might be changed to look at who the user really is that is invoking the su to root and permit only su to root for those in wheel, while leaving the su to anyone else available for normal users. With my servers being exposed to the world I am as careful as I can and one of those has only three accounts with shell access. I drive to the colo every month or so visit them - to make sure I don't smell smoke or have the drive bearings going. At 130AM it's only a 15 minute drive - in traffic it's nasty. And I have to remember to bring the security badge and my right hand for the biometric scan after the badge turns it on. I just felt that the su man page is misleading in that it basically says only members of the wheel group [if it exists] can su to root. But su to another user in wheel and su to root is not even listed as a bug. A friend of mine verified that this 'hole' has existed as far back as the 4.3-Reno he used. With today's heightened security I'm just thinking it could be time to tighten up that potential hole. Your thought on changing permissions is good and I may implement that. Just an additional safeguard if some other program springs a leak and permits access where it should not. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message