Date: Wed, 27 Mar 2002 11:44:30 -0700 From: Nate Williams <nate@yogotech.com> To: bv@wjv.com Cc: Tom Rhodes <darklogik@pittgoth.com>, freebsd-security@FreeBSD.ORG Subject: Re: Question on su / possible hole Message-ID: <15522.4878.525099.369944@caddis.yogotech.com> In-Reply-To: <20020327183548.GI30556@wjv.com> References: <20020327140006.GA30556@wjv.com> <20020327110616.58e6ead1.darklogik@pittgoth.com> <20020327180713.GF30556@wjv.com> <20020327133238.48e32908.darklogik@pittgoth.com> <20020327183548.GI30556@wjv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Then restrict su, as others have pointed out. There should be *NO* reason on your Colo box for anyone to use su, other than to gain root, correct? > 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. That's because once you su to another user, you *ARE* the other user, and you have *ALL* the rights and privileges of that user. The chown/chmod manpages don't talk about setting /bin/sh to root.wheel and mode 4755 as a way to give everyone root access either, but it's certainly possible. The manpages are there to describe common behavior. If a user is silly enough to have an easily guessed password (or gives it out), and the root password is also easily guessed (or given out), then the computer is unsafe, regardless of su's behavior. > 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. I don't consider it any more a potential hole than *any* other 'potential' hole. Should the FS disallow someone from creating setuid/setgid binaries, since there is the potential for someone to abuse that feature as well? Tools, not policy. Nate 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?15522.4878.525099.369944>