Re: su - user question
On Mon, 2002-01-21 at 23:40, martin f krafft wrote:
<snip>
> nevertheless, leave a root console open on a production machine really
> just calls for trouble. imagine you are about to head for lunch with a
> friend, but you decide to check something in the server room quickly.
> while you stare at your Annex ports or your Cisco switch, your friend
> idles around and notices the root console. had there not been a root
> console, he would have never thought of doing what he now does, but
> since the prompt "#" is so inviting, he takes all of 20 seconds to
> install a backdoor in the system, binding a shell to a high port,
> installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing
> /etc/shadow to himself etc.
Martin, it's a server in my spare room :-) The only person installing a
backdoor on the server would be an unlawful intruder. Or a cat who can
type ;-) Your points are well taken and I would follow the same security
practices as you.
<snipped useful discussion of an exploit>
> i think that you have a conceptual problem with what a server and a
> workstation are, and their differences, and what a superuser account is
> to be used for. in all but the rarest cases do production servers even
> have local accounts, and if, then usually without shell access. yes, i
> know that there are companies and institutions that provide shell
> access, but they usually have dedicated servers for that.
Martin, I'm only an individual writing from one of my "servers". And if
I can save resources by using a server for a workstation as well I think
that's OK.
> i don't have the time to research and present an escalation exploit at
> this moment, but i do want you to accept one point, which in itself will
> already flaw your approach of handling login and usage of the
> workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and
> it's an accounting thing. there's a reason why the group "wheel" exists
> on traditional UNIX systems (*why* does Linux *not* have it); noone
> without a local account should be allowed root, and it's good to know
> who became root when; to become root, you have to know two passwords
> *and* an account name.
I do not see that there is any significant security issue in logging in
as root from a LOCAL console.
> you have it backwards. usually, you login as user and su to root.
> logging in as root and su'ing to a user is the wrong way around. i even
> think it's wrong to allow password-less su and suggest to disable it.
Whenever I use a remote login procedure like SSH I log in as a user and
then su to root when necessary.
Since you "even think it's wrong to allow password-less su and suggest
to disable it" you're really going to like trying to refute this
"heretical" scenario I created:
Here's a scenario where using su - could be less risky than always
logging in as a user:
First assume there is a local root vulnerability in the operating
systems of two computers that can be accessed once a user level account
has been obtained.
Second, assume that the root passwords of both systems are very strong.
Third, assume that the systems are logged into locally by a
user/administrator. However they are connected to the Internet and are
providing Internet services (it's not the best security practice to
allow remote logins when they are not necessary but it's still a
plausible scenario).
In the first system the administrator sets up a user account with an
easy to remember password. Over time a cracker is able to guess this
password and obtain local user and then root access to the computer.
In the second system the administrator sets up a user account with a
randomly generated dual case alphanumeric password. The administrator
has to write this password down to remember it. Consulting the document
is a hassle so he/she decides to use su - to log in as the user instead.
The remote cracker is never able to guess the user password and obtain
user (then root) access to the system.
This indicates to me that the increased risks of using su - to log in as
a user may be offset by the decreased risks of a superior user password
that you actually have to write down and consult to remember.
Or to put it another way in some circumstances it may be superior for an
administrator/user to only have to remember one long password than
trying to remember two potentially less effective passwords. The user
password can be even _unknown_ to the user.
Regards,
Adam
Reply to: