NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/sgi/admin/121

Internet Message Format | 1993-01-07 | 6.1 KB

Xref: sparky comp.sys.sgi.admin:121 comp.sys.sgi:18547
Path: sparky!uunet!spool.mu.edu!olivea!sgigate!odin!sgihub!zola!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Newsgroups: comp.sys.sgi.admin,comp.sys.sgi
Subject: Re: security concerns revisted
Message-ID: <[e-mail]>
Date: 7 Jan 93 06:51:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 101

In <[e-mail]> [e-mail] (Mark Bartelt) writes:
| Sorry to continue grousing, but ...  Although my feelings about SGI as a
| company are, for the most part, strongly in the "warm and fuzzy" category
| (due in large part to people like Dave and a host of others who provide
| great technical support via the net), I nonetheless feel that SGI tends
| to display a rather cavalier attitude toward security.

I strongly disagree.  We have fixed and released every *real* security
bug found quite quickly.  Where the disagreement happens is on things like
open root (and lp, etc.) accounts as shipped.

I maintain (and a number of people disagree with me), that you *have*
to ship an open root, and given that, anybody who can't scan a
*15 line* password file to notice the other accounts that have no
passwords is unlikely to do anything about root either.  If they
don't secure root, nothing else matters.  We can start all of these
arguments all over again, but I maintain (both as a system admin in
a number of environments, and as a tech support resource in 4 compainies)
that we would be *crazy* as a company to do anything else.

I also maintain that any site that allows J. Random User to hook up
their system to a network connected to the internet, with no supervision
at all, and *then* complains about lack of security is just blowing
smoke.  This isn't a popular position with some folks, it should be noted ;)

As has been discussed here every time this has come up (and as Vernon
mentioned in this same thread), the best thing would be to have a script
that runs after install, similarly to the autoconfig and confmsg scripts,
that asks the user if they want to setup a secure system, and walks them
through it in a script.  That may still happen for a future release.

| I think that, if provided with wide-open tftpd as an option, people from
| both categories will sometimes forget to put it back.  (I did it myself
| once.  Hey, since most of us have at least twice as much on our to-do
| lists as there is time available, things do get hectic at times.)  And
| people in group (2) may not realize all the implications of leaving an
| unrestricted tftpd running.  And even if *everybody* remembered to put
| it back *every* time, there would still be time windows during which a
| nefarious creep could grab files.

Yes, but if you are *that* paranoid, you should be installing only from
local media.  Really, you can't get all that much with just tftpd as
shipped, even without -s.  Any file that you care to keep secure (with
the possible exception of /etc/passwd, as noted by Vernon) isn't going
to have world read and/or write permission anyway.

| Since unrestricted tftpd is unnecessary, I suggest that it's safer all
| around if the documentation wouldn't even propose it as one of several
| options.  Just expunge the suggestion from the documentation.

That won't happen.  As I said, we simply got too many phone calls to
support from people who couldn't handle it.  Since we list both in
the same paragraph, do it the way you like, and don't use the other
(or do local installs).

| In the past year, our campus has been hit with tftp probes from outside,
| attempting to grab /etc/passwd; and many system administrators weren't
| even aware of it.  And several of them (on both SGI and non-SGI systems)
| had unrestricted tftpd enabled, and had their /etc/passwd grabbed.

Getting /etc/passwd isn't necessary, given how easy it is to snoop
network traffic for passwords, although it may make it simpler.
We will have shadow passwords in the next major release, which alleviates
the grabbing /etc/passwd issue.

| Sorry to rant, but I think someone is underestimating the seriousness of
| the situation.  And since SGI seems to be attempting to target more of a
| less-sophisticated class of customers (positioning the Indigo as sort of
| a high-end PC, for example), one would hope that you folks would try to
| err on the side of defaulting to too much security rather than too little.

The less sophisticated users will either not follow instructions at all
(so anything is hopeless) or follow them quite closely (so things are
in pretty good shape).  Very few are in between.  Besides, most of those
more naive users are either not on the internet, or are at sites where
somebody can help them get things setup.

| Yes, everything is pretty well documented, but there's a lot of stuff to
| read, and not all your new customers will read it all; and of those who
| do, many may not fully digest what they read.

*MOST* people will never read the documentation, even after they get
into trouble.  The exceptions either skim it, or read it pretty thoroughly.
Again, it is somewhat surprising (to those who haven't been exposed to
it all too often) how few people fall into the in-between cases.

| Password-free accounts, and pointing people toward permissive tftpd, seem
| like poor ideas.  And commenting that the potential pitfalls are covered
| in the documentation strikes me as a bit of a cop-out.

See above.  As a systems company, we simply don't have any choice, unless
all of you want to pay a lot more for support, or are willing to live
with even longer delays whenever you call for support.

| ( Don't take any of this personally, Dave; we *do* love you! :-)

No problem, I like to argue, just ask any of my co-workers and managers!
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]