[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU su and the wheel group

From: Sam Holden
Subject: Re: GNU su and the wheel group
Date: 5 Oct 2004 04:42:52 GMT
User-agent: slrn/ (Linux)

On Tue, 05 Oct 2004 04:19:58 -0000,
        <> <> wrote:
> Sam Holden <> wrote:
>> On Mon, 04 Oct 2004 23:25:49 -0400, Paul Jarc <> wrote:
>>><> wrote:
>>>> [root]# ls -l /bin/su
>>>> -rwsr-x---    1 root     wheel       94625 Oct 12  2003 /bin/su
>>>> Now only members of the wheel group can run su... how exciting!
>>> And I would say that this itself makes a better argument against
>>> having code in su to check for the wheel group.  Less code to verify
>>> is good, especially in such a security-sensitive program.
>> What about the poor souls who want to su from one user account to
>> another?
> How realistic is this?
> The only time I can remember using this is when I have muiltiple
> accounts for myself on the same machine for test purposes and I'm
> too lazy to properly log in to a different account. This was in a
> low security test environment.
> In most production environments I would suggest that each user
> gets exactly one account, they never tell anyone their password
> and they do all operations as that user. If they REALLY need
> a special operation for some special purpose then a suid program
> would have to be written that does exactly that operation.
> Can anyone think of a sensible example where normal users are
> using su to switch accounts?

One user screwing up their .profile (or equivalent) and suing
from another user's account in order to fix the file (which is
sufficiently broken to terminate any shell that sources it,
running "exit" for example). 

> OK, suppose each user has one account for connecting to some
> financial server and a different account for doing email.
> If we presume that the email account is less trusted (possible
> trojans, etc) then we can't trust anyone to run su from that
> account either (because somehow the su might get trojaned and
> betray the password of the trusted financial account).

What about going the other way? suing from the trusted
account to the other account in order to run an email

Sam Holden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]