🚀 go-pugleaf

[ me ]

| Section 3.2 of the IRIS Software Installation Guide ("Enabling Network
| Access to Remote Workstations") suggests modifying inetd.conf so that
| tftpd runs in unrestricted mode.  I wonder how many people have done
| this, and have forgotten to put tftpd back into restricted mode.

[ Dave Olson ]

| That *exact* same section explictly reminds you to put it back.
| It *also* tells you how you can modify the entry to leave security
| on, but only allow a couple of directories.

[ me again ]

| But my question is, why should this ever be necessary at all?  Right
| after suggesting that the tftpd "-s ..." stuff be removed, the guide
| tells us that we might want to consider appending "<CDdir>/dist" (or
| whatever) to the "-s /usr/local/boot" at the end of the tftpd entry
| in inetd.conf instead, which certainly seems preferable.

[ Dave again ]

| Because we did *just* that first, and an amazing number of people didn't
| seem to be able to handle the typing involved ;)

[ me yet again ]

| Given the security worries related to a unrestricted-mode tftpd, why
| does the documentation even suggest running it that way in the first
| place?

[ Dave once more ]

| See above.

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.

You basically have two types of customers: (1) experienced, sophisticated
computeroids; and (2) people who want to use their IRISes as tools to get
a job done, and whose level of computer expertise may be minimal.

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.

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.

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.

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.

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.

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.

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

Mark Bartelt                                                416/978-5619
Canadian Institute for                             mark@cita.toronto.edu
Theoretical Astrophysics                           mark@cita.utoronto.ca

"Clothes not busy being worn are busy drying."  -  Dylan, on laundry day
          [ singing "It's all right, ma (I'm only bleaching)" ]