NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/security/misc/2608

Text File | 1993-01-26 | 3.9 KB | 82 lines

Newsgroups: comp.security.misc
Path: sparky!uunet!ceilidh!dnichols
From: [e-mail] (DoN. Nichols)
Subject: Re: Unix Viruses. Are there any??
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet)
Nntp-Posting-Host: shindig
Organization: D and D Data, Vienna VA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 26 Jan 1993 05:13:33 GMT
Lines: 69

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Ove Hansen) writes:
>>In article <[e-mail]> [e-mail] (Carl Brewer) writes:
>>|>In article <[e-mail]> [e-mail] (James Michael Chacon) writes:
>>|>>[e-mail] (Len Senetza) writes:
>>|>>
>>|>>>this assumes that root has . in its path, and how many root accounts
>>|>>>out there do?
>>|>>
>>|>>A scenerio like this assumes that the sysadmin is a pretty trusting person
>>|>>and probably already has large security holes in the system.
>>|>
>>|>a scenario like this assumes that the sysadmin should not be a sysadmin.
>>
>>Now, Remember that the majority of sysadmins are part-timers who have better
>>things to do in their company than tighten up the security holes that the
>>vendors leave in the systems they sell. In most small companies I have seen

    [ ... ]

>Actually, I think  the system  should come as it comes. If  a computer  was to
>come with high security, the same  computer-iliterate  sysadmin  would  hardly
>ever bother to open it.  Niether would  (s)he  ever  figure out  how to export
>directories  to clients. Or how to allow  users  to  rsh  from one  client  to
>another  without a password. Or why ping won't  run after cd /usr/etc (about .
>in $PATH).

    Hold on a minute!  While I generally agree with you, your last
sentence here implies that if '.' is not in $PATH, even though the directory
in question (/usr/etc) *is* in $PATH, that when you have made /usr/etc into
'.' by cd'ing to it, that the system will refuse to run your program (ping
in this case).  Well, I never knew that to be the case, and on my Sun
running SunOs 4.1.1, it is *not* the case.

>Of course, closed, "secure" system is easier to manage. But most computers are

    Well, that depends on just *how* secure it is.  If it is around the
B or A levels of security, managing it is far more of a pain.  (As, no
doubt, is dealing with all the paperwork to keep it ceritified at that
level. :-)

>bought for users,  not  for managers  :) And I  bet  that there are many sites
>where users would  rather have insecure but functional system. After  all,  if
>you only have local area  network and just several users \n is probably a good
>root password.

    Even for the boxes which are in my *home*, and only accessable from
outside through the only system with a dialin modem, I would never use
'\n' as a root password.  I occasionally have small to medium-sized childen
in here, and while they may be well intentioned, I shudder to think of what
they could damage with a few random pokes at a keyboard.

>Having said that I agree that it would be nice if manufacturies gave us some
>hints about how to make system more secure if needed (or perhaps even shell
>scripts to do the convertion).

    Yes, perhaps a notice on top of the documentation or even taped to
the cpu chassis, depending on size:

      "NOTICE - Your system it totally insecure as shipped!  If security
matters to you, go to section foo in manual binder bar to determine the
things that need to be done, how, and why.  If you don't, don't say we
didn't tell you."

--
 Email:   <[e-mail]>  |  ...!uunet!ceilidh!dnichols
         <[e-mail]>
 Donald Nichols (DoN.)  |   Voice (Days): [phone] (Eves): [phone]
    --- Black Holes are where God is dividing by zero ---