Strange command histories in hacked shell history

[Bill Vermillion]

Deep in the forest in the dark of night on Fri, Dec 17, 2004 at 20:11 
with a cackle and an evil grin Elvedin Trnjanin cast another eye of
newt into the brew and chanted:

> Bill Vermillion wrote:
> 

> >Can anyone explain why  su   does not use the UID from the login
> >instead of the EUID ?  It strikes me as a security hole, but I'm no
> >security expert so explanations either way would be welcomed.

> Because su does exactly what is says.  From the manual -
> 

>    DESCRIPTION
> 
>     *su* requests the password for /login/ and switches to that user and 
>     group ID
>     after obtaining proper authentication.
> 

I understand that after using Unix for about 2 decades.
However in FreeBSD a user is supposed to be in the wheel group [if
it exists] to be able to su to root.

But if a person who is not in wheel su's to a user who is in wheel,
then they can su to root - as the system sees them as the other
user.  This means that the 'wheel' security really is nothing more
than a 2 password method to get to root.

If the EUID of the orignal invoker is checked, even if they su'ed
to a person in wheel, then they should not be able to su to root.

I'm asking why is this permitted, or alternatively why is putting a
user in the wheel group supposed to make things secure, when in
reality it just makes it seem more secure - as there is only one
more password to crack.

>  DESCRIPTION
> 
> *sudo* allows a permitted user to execute a /command/ as the superuser 
> or another user, as specified in the /sudoers/ file. The real and 
> effective uid and gid are set to match those of the target user as 
> specified in the passwd file and the group vector is initialized based 
> on blah blah blah...

And I use this for about two people who need extra levels to do
certain things for their web sites.

Bill
-- 
Bill Vermillion - bv @ wjv . com