Sun-Spots-Request@RICE.EDU (Vicky Riffle) (09/02/87)
SUN-SPOTS DIGEST Wednesday, 2 September 1987 Volume 5 : Issue 38
Today's Topics:
Re: Sun 3.4 problems (2)
Re: Modems and Security (2)
Root non-security on SUN workstations
Re: Choosing Internet addresses (2)
Re: 32 bit disk controller for Sun 3
NFS & NeWS Seminars, Boston Sept. 10,11
Tape controller for STC drives?
Non-68881 version of tcpdump?
Porting Berkeley MAGIC to SUN's with AED's?
A problem with accton?
What does "text:table is full" mean?
RCS for Suns?
clocktool icon with numbers
----------------------------------------------------------------------
Date: Fri, 28 Aug 87 16:57:29 CDT
From: knutson@mickey.cc.utexas.edu (Jim Knutson)
Subject: Re: Sun 3.4 problems (1)
We were having similar problems with our Sun 2/50s. Watch the boot kernel
messages on your diskless machines. Right after the using nnn buffers
message, you should see a revarp request and then a setting submask
message. If you see the subnet mask get set backwards (e.g. 0x0000ffff
instead of 0xffff0000) then you will end up with a broadcast storm.
We found that the problem of hosts sending incorrect subnet masks not to
be limited to the WIN/TCP Ver 3 software for VMS VAXs. In fact, all or
our 4.3 BSD hosts looked to be answering with the subnet mask backwards.
This will cause problems with SunOs 3.3 or 3.4. Can anyone verify that
the 4.3 BSD code is broken as well?
Jim Knutson
knutson@ngp.utexas.edu
------------------------------
Date: Fri, 28 Aug 87 13:49:41 PDT
From: Fernando Pereira <pereira@stinson.ai.sri.com>
Subject: Re: Sun 3.4 problems (2)
We had exactly the same problem when we brought up 3.4 (from 3.2). The
solution is hidden in the 3.4 manual, pp. 53-54. With the 3.3 upgrade,
subnet support was added. As a result, a subnet mask is used to restrict
broadcast packets to the appropriate subnets. This subnet mask should be
specified with the "netmask" parameter to /etc/ifconfig, for each relevant
interface in the /etc/rc.boot file for the server. The subnet mask for
class C networks (like ours) is 0xFFFFFF00, or 255.255.255.0 in Internet
address format. Thus, the call to ifconfig in rc.boot might be
/etc/ifconfig ie0 $hostname netmask 255.255.255.0 -trailers up
After making this change, reboot the server and the clients and all should
be OK.
I wish Sun had repeated this information in a more visible place in the
3.4 "read me first", it would have saved us a lot of grief.
-- Fernando Pereira
AI Center
SRI International
pereira@ai.sri.com
------------------------------
Date: Fri, 28 Aug 87 16:05:28 EDT
From: bzs@bu-cs.bu.edu (Barry Shein)
Subject: Re: Modems and Security (1)
This problem (finding yourself in another's account over a modem) is
invariably caused by some combination of:
1. Not setting up the flags variable in the system's config
file to honor modem control, eg:
mti0 ... flags 0x0000 ... # all 16 mti ports wired correctly
2. Not wiring the modem properly, thus defeating the receipt
of a hangup signal (eg. jumpering various pins even tho the
flags field is right.)
The flags field in the config file should have zeros in the bits
corresponding to lines where modem control is desired. This is all
explained on the appropriate manual page for the interface (eg. zs or
mti.) Once set you must re-build a kernel, install it and reboot the
system for it to take effect.
So the security you mention is there and readily available, people just
have to make use of it, it's trivial.
-Barry Shein, Boston University
------------------------------
Date: Tue, 1 Sep 87 14:31:11 EDT
From: scott@bu-ma.bu.edu
Subject: Re: Modems and Security (2)
In Volume 5 #37, adler1@brandeis.bitnet writes:
> I've noticed that the modems on the SUNs all have a quirk which seriously
> undermines the security on these systems and that is what I want to ask
> about. What happens is that I will dial up the number and instead of
> getting a login promt or a CONNECT signal, I will simply find myself
> logged into someone's account!... I have been told by one person that
> this is a weakness of UNIX systems in general and quite difficult to do
> anything about....
>
> How can one eliminate this problem?
We had a similar problem on our machine a while back. The problem was
solved when we reconfigured our kernel with the right flags for the
mti0 device. Specifically we changed
device mti0 at vme16d16 ? csr 0x620 flags 0xffff priority 4
to
device mti0 at vme16d16 ? csr 0x620 flags 0x0000 priority 4
rebuilt the kernel, and the problem went away.
Scott Sutherland (scott@bu-ma.bu.edu)
Boston University Math Dept.
------------------------------
Date: Fri, 28 Aug 87 20:47:34 EDT
From: Steve Simmons <umix!itivax!lokkur!scs@rutgers.edu>
Subject: Root non-security on SUN workstations
Various folks have had interesting discussions about security on Suns,
given that the workstation is a console and can be booted in single-user
mode. All the the suggestions were some variant on modifying the login
done by the rc file so as to make it difficult to get in. Many thanks to:
Bruce G Barnett <barnett@vdsvax.steinmetz.uucp>,
Brent Chapman <chapman@eris.BERKELEY.EDU>,
Alexander Dupuy <dupuy@amsterdam.columbia.edu>,
David Robinson <david@elroy.Jpl.Nasa.Gov>
and others I've missed.
The discussion misses a fundamental problem which I suspect is the case in
most environments (including, unfortunately, ours). If a company has a
lot of workstations that are permanently assigned to users, the users
usually have the root passwords. This is a convenience in one sense, in
that the system administrator (me) doesn't have to do all the root work
for 140+ workstations. (By the way, don't blame me -- I inherited the
situation, and don't carry the political weight to both (a) change it, and
(b) hire more folks to do all that work).
So -- none of these do any good to protect you from the malicious in-house
user. Just login as root, su to someone's account, and off you go.
What I want is a module that can be compiled into the workstation kernal
that *will not allow a single-user boot*. Period. No rc files or
profiles that some clever cracker will quickly edit out, no new
complications to make these suckers harder to take care of. Make it an
optional module, so devotees of open systems (is my sarcasm showing?)
don't have to change. This gives me a reasonable degree of certianty in
saying that if there was a breakin starting from workstation X, X's owner
was responsible.
For the day when we finally manage to take away the workstation root
passwords (it will come, when management gets hurt enough by breakins and
pranks and decided to fund what's needed), anything that needs done on
that workstation my staff can do by coming in from the file servers. We
set things up so that a client's server appears in the /.rhost file. If
worst comes to worst, we shut off the client and play with his nd
partition from the server. *You just don't need a root id on a diskless
node.*
Steve Simmons, Inland Sea Software, Ltd.
Real Mail: ...ihnp4!itivax!lokkur!scs
Fake Mail: 9353 Hidden Lake, Dexter, MI. 48130
------------------------------
Date: Fri, 28 Aug 87 17:25:26 EDT
From: stpeters%mozart.tcpip@ge-crd.arpa
Subject: Re: Choosing Internet addresses (1)
> you're supposed to get your own authorized Internet net number and
> use it on all of your machines.
>
> [[ Absolutely! ...
Not quite so absolutely! For most cases, this is good advice, but there
*are* exceptions. When we first installed a sitewide Ethernet, there were
two good reasons why we went with an unregistered class A network number
of our own choosing:
First, we had machines whose TCP/IP implementations only supported
class A addressing. (Don't laugh too hard - I think our first Sun 1's
(Sun OS 1.0) only supported class A, but I'm not sure - at the time I
didn't know the difference. Many vendor's initial TCP/IP offerings only
supported class A, because then they didn't have to implement ARP: they
just used the Ethernet host number as the class A IP host number.)
Second, we're a big site. *We* knew we would eventually have
hundreds of hosts, but the NIC told us we'd have to argue pretty hard
(i.e., red tape) to get a class B number. By choosing our own class A
network number, three of us had our three conclaves of Suns along a very
long Ethernet talking in minutes. No red tape at all.
Now we have more than the 255-host class C limit on our net and could
easily justify a class B net number, but I'm not sure that we don't still
have some primitive TCP/IP's. Anyway, our security hounds would never let
us connect to The Internet - they had fits enough when we just wanted to
connect to each other.
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa
uunet!steinmetz!stpeters
[[ Nonetheless, any time you use an Internet address that was not
officially issued to you by the NIC, you are treading on very thin ice.
If you really have to do this, you should be VERY sure of two things: (1)
the usage will be completely temporary (don't start using it and then
"forget" to change it to a real one) and (2) there is ABSOLUTELY no
possible way for your packets to stray out into the real world. Because
if they do, you will have system administrators and the net police all
breathing down your neck!!! --wnl ]]
------------------------------
Date: Sun, 30 Aug 87 17:38:21 -0100
From: Richard Tobin <richard%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Subject: Re: Choosing Internet addresses (2)
> Sun and DEC both use Internet addresses as examples in their literature.
> But you aren't supposed to use their example addresses: you're supposed to
> get your own authorized Internet net number and use it on all of your
> machines.
"Installing Unix", p9:
"Please remember that you can use Sun Microsystems' default number
(192.9.200) if you have not been assigned a network number by ARPA,
or if you are not connected to a higher level network."
That's the 3.2 manual. We chose a network number back in the days of
release 1.1, when it was a little more explicit:
"Sun 120/170 Installation Manual", p3.5:
"If you have been assigned a network number by ARPA use that number.
If not, or if the entire network number business has you confused, use
Sun's default network number of 192.9.200."
So it's not by any means just a case of people dumbly copying the
examples.
> The folks at the NIC will assign an Internet number to anyone
> using the Internet protocols. You don't need to be connected to the
> Internet. (Their user assistance number is 800-235-3155. That might be a
> good place to start.)
That number doesn't seem to work from Scotland :-)
[[ It might if you put the appropriate international dialing prefix in
front of it! --wnl ]]
Do they have an electronic mail address? :-) :-)
[[ According to RFC 997, it is HOSTMASTER@SRI-NIC.ARPA. So there! --wnl ]]
Richard Tobin, JANET: R.Tobin@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
------------------------------
Date: Mon, 31 Aug 87 12:47:40 EDT
From: David S. Hayes <sundc!hqda-ai!merlin@seismo.css.gov>
Subject: Re: 32 bit disk controller for Sun 3
> A Xylogics salesman told me that his company has, and that Sun will later
> this year release, a 32 bit disk controller for the VME bus. He says that
> the current 16 bit controller is just a Multibus-VME converter.
I have heard this also. I've gotten the same story now from 3 different
sources, and 2 of them were Sun internal. So it's probably true. Sun is
waiting for additional VME controller manufacturers to come up to
production volumes, so they can second-source their stuff.
Xylogics already has their 700-series VME controllers. They also have Sun
device drivers. They contracted Sun Consulting to write them, so it's a
good bet that they will work in a Sun. The problem is that your boot
drive must still be a 45x controller, since the Sun boot proms have never
heard of a 700 Xylogics.
------------------------------
Date: 28 Aug 87 23:06:50 GMT
From: sxn@sun.com (Stephen X. Nahm)
Subject: NFS & NeWS Seminars, Boston Sept. 10,11
Lachman Associates, Inc. and Sun Microsystems, Inc. will be presenting one
day seminars on NFS (tm) and NeWS on September 10 and 11. Walk-ins are
welcome. Pardon the marketing-ese in the descriptions below.
Here is a summary of the two seminars:
NFS Seminar
This seminar will present a technical overview of NFS, its design and
implementaion, experiences in porting NFS to various computers and
operating systems (include UNIX (r) System V and MS-DOS), and how NFS is
distributed. Jointly sponsored by Sun and Lachman Associates, Inc., this
seminar should be attended by engineers and managers from computer
manufacturers and by large end-users who are interested in NFS.
Network Windows Seminar
NeWS (Network extensible Window System) is the first system to take
advantage of PostScript (tm), the image description language developed by
Adobe Systems and endorsed by both Apple and IBM. [[ I think they mean
"the first *windowing* system" --wnl ]] Learn how NeWS works, and see it
in action at a seminar taught by the engineers who developed it. If you
are a computer manufacturer planning a product using windows or a software
engineer developing an application that will work in a window environment,
the information in this seminar is of critical importance to you.
Dates: Sept. 10, 1987 - NFS Seminar
Sept. 11, 1987 - Network Windows Seminar
Time: 8:00 AM - Registration
9:00 AM - 5:00 PM - Seminars
Place: Sheraton Tara Hotel
1657 Worcester
Framingham, MA 01701
(617) 879-7200
Cost: NFS Seminar: $75.00
Network Windows Seminar - $75.00
Preregistration: Pat Nolan, Lachman Associates
1-800-LAI-UNIX
In Illinois: 312-505-9100 ext. 236
NFS is a trademark of Sun Microsystems, Inc.
UNIX is a registered trademark of AT&T.
PostScript is a trademark of Adobe Systems.
Steve Nahm sxn@sun.COM or sun!sxn
------------------------------
Date: Fri, 28 Aug 87 12:05:28 PDT
From: sklower%vangogh.Berkeley.EDU@berkeley.edu (Keith Sklower)
Subject: Tape controller for STC drives?
Does anyone know of/have experience with a tape controller for STC
interface drives for sun3's? (We are decomissioning a vax and already
have the drive, so we are stuck with STC rather than Pertec interfacing.)
------------------------------
Date: 28 August 1987 14:46 PDT (Friday)
From: bierma@nprdc.arpa (Larry Bierma)
Subject: Non-68881 version of tcpdump?
Does any know where I can get a copy of Van Jacobson's "tcpdump" program
that doesn't require the 68881 floating point chip. I need to run it on a
3/50 that has no floating point chip. The copy of "tcpdump" I have
requires it.
--Larry ARPA: bierma@nprdc.arpa
UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma
PSTN: (619) 225-2161
------------------------------
Date: 27 Aug 87 22:00:34 GMT
From: usfvax1!brankley@usfvax2.UUCP (Bob Brankley)
Subject: Porting Berkeley MAGIC to SUN's with AED's?
Help!
I just started working at a place that appears to be running the latest
copy of MAGIC from Berkeley and wants to port it to a SUN fileserver using
AED terminals. Although a seemingly bizarre thing to do, we hoped to used
the fileserver as a number cruncher for the 3 AED's we currently use on
our VAX under 4.2 BSD. Think of it as economic pressure versus what would
be nice.
Since 4.2 BSD and SunOS 3.2 are pretty much the same stuff, most of the
VAX/AED code compiles correctly on the server when the make is
appropriately tricked into thinking it is running on a VAX. However, one
of the graphics drivers does use a VAX assembly routine, and I do not know
VAX assembly at all. The routine does seem important, even though I have
little idea what it does.
What I would really like to know is if anybody has attempted this type
of port before, as well as how the port went. I contacted the guys at
Berkeley about it and they said they have only tried porting MAGIC using
Sun's graphics terminals and not AED's. I would really appreciate any
information I can get on how to attempt the port. I can be reached via
e-mail at the below addresses. Thanks for your help in advance.
Bob Brankley
Assistant Administrator, usfvax1
CSNET: brankley%usfvax1@usf.edu
brankley@usf.edu
UUCP: {gatech, gatech!codas}!usfvax2!usfvax1!brankley
{gatech, gatech!codas}!usfvax2!brankley
------------------------------
Date: Mon, 31 Aug 87 14:05:57 CST
From: AARON KONSTAM <79343382%TRINITY.BITNET@wiscvm.wisc.edu>
Subject: A problem with accton?
Has any one seen the following problem and knows how to fix it.
We have a 3/160 and two diskless 3/50's running version 3.2 of the Sun
operating system. On the 3/160 and one of the 3/50's accton runs as it
should. On the other 3/50 if one types:
accton
the machine respons with:
accton: invalid arguments
Why is this happening? In honesty I must note the major difference
between the 3/50's is the placing of the kernal. The 3/50 on which accton
works has its kernal in the public partition and a soft link to the kernel
in the root partition. The other 3/50 has its kernel in its root partion.
This machine boots and the boot script executes accton without error but
the accounting is not started.
You can repond directly to me or post the answer in sun-spots if it is of
general interest.
Aaron Konstam
Trinity University
79343382@trinity.bitnet
------------------------------
Date: Mon, 31 Aug 87 11:16 PST
From: <JON%UCLASTRO.BITNET@wiscvm.wisc.edu>
Subject: What does "text:table is full" mean?
To all a general question,
At the moment, we have a 3/260 server and a 3/160 client. Every once in a
while, when someone is using Suntools on the 260 and has a number of
windows open, the system starts generating messages that look like:
text:table is full
on the console. I understand that this is some type of memory problem
(eventhough the 260 has 32Mb). Being a non-unix guru, I do not know where
to go from here. HELP!!!
Thank you for your time,
Jonathan Eisenhamer
UCLA Astronomy
JON@UCLASTRO.BITNET
BONNIE::JON (SPAN 5828)
(213) 206-8596
------------------------------
From: umn-cs!haberman@rutgers.edu (Joe Habermann)
Date: 31 Aug 87 19:59:55 GMT
Subject: RCS for Suns?
Is there RCS sold (or public domain) for the Suns? Help!
- Thanks
Joe Habermann
rutgers!meccts!umn-cs!haberman
haberman@umn-cs.ARPA
haberman@umn-cs.cs.umn.edu
------------------------------
Date: 29 Aug 87 13:40:20 GMT
From: elijah!tarsa@seismo.css.gov (Greg Tarsa)
Subject: clocktool icon with numbers
Here's a version of the clocktool icon that has the hours in arabic around
the outside, instead of tick marks.
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0x8888,0x88BF,0xFC88,0x8888,0x8888,0x8BFF,0xFFC8,0x8888,
0x2222,0x2FE0,0x07F2,0x2222,0x2222,0x7E04,0x607E,0x2222,
0x8888,0xF00C,0x900F,0x8888,0x888B,0xC004,0x1003,0xC888,
0x2227,0x0004,0x2000,0xE222,0x223E,0x4404,0x4004,0x7A22,
0x88B8,0xCC0E,0xF00C,0x1C88,0x88F0,0x4400,0x0004,0x0E88,
0x22E0,0x4400,0x0004,0x0722,0x23C0,0x4400,0x0004,0x03A2,
0x8980,0xEE00,0x000E,0x0188,0x8B00,0x0000,0x0000,0x00C8,
0x2700,0x0000,0x0000,0x00E2,0x2600,0x0000,0x0038,0x0062,
0x8C98,0x0000,0x0008,0x0638,0x9DA4,0x0B0E,0x1C08,0x0938,
0x38A4,0x0C91,0x2208,0x011A,0x38A4,0x0811,0x0208,0x021A,
0xB0A4,0x081F,0x1E08,0x040C,0xB1D8,0x0810,0x2208,0x0F0C,
0x7000,0x0811,0x2208,0x000E,0x6000,0x080E,0x1E08,0x0006,
0xE000,0x0000,0x0000,0x0006,0xE000,0x0000,0x0000,0x0006,
0xE000,0x0000,0x0000,0x0007,0xC000,0x0000,0x0000,0x0003,
0xCC00,0x0000,0x0000,0x0033,0xD200,0x0000,0x0000,0x004B,
0xD200,0x0001,0x8000,0x000B,0xCE00,0x0003,0xC000,0x0033,
0xC200,0x0003,0xC000,0x000B,0xD200,0x0001,0x8000,0x004B,
0xCC00,0x0000,0x0000,0x0033,0xC000,0x0000,0x0000,0x0003,
0xC000,0x0000,0x0000,0x0003,0xE000,0x0000,0x0000,0x0007,
0x6000,0x0408,0x0000,0x0006,0x6000,0x0400,0x0000,0x0006,
0xE000,0x1F38,0x6870,0x0006,0xF000,0x0408,0x5488,0x030E,
0x30C0,0x0408,0x5488,0x050E,0x3120,0x0408,0x54F8,0x090E,
0x9920,0x0408,0x5480,0x0F98,0x98C0,0x0408,0x5488,0x0118,
0x3920,0x0308,0x5470,0x013A,0x2D20,0x0000,0x0000,0x0032,
0x8CC0,0x0000,0x0000,0x0068,0x8E00,0x0000,0x0000,0x00E8,
0x2300,0x3C00,0x0000,0x00E2,0x2380,0x2400,0x001E,0x01A2,
0x89C0,0x0400,0x0010,0x0388,0x88E0,0x0800,0x001C,0x0788,
0x2270,0x1001,0x8002,0x0E22,0x2238,0x1002,0x4012,0x1E22,
0x889E,0x1002,0x000C,0x7888,0x888F,0x0003,0x8000,0xE888,
0x2223,0xC002,0x4003,0xE222,0x2222,0xF002,0x400F,0x2222,
0x8888,0xFE01,0x807E,0x8888,0x8888,0x8FE0,0x07F8,0x8888,
0x2222,0x23FF,0xFFE2,0x2222,0x2222,0x223F,0xFE22,0x2222
Tarsa Software Consulting
33 Seabee Street
Bedford, NH 03102
(603)668-8349 {decuac,decvax}!elijah!tarsa
[[ Also available in the archives under the name "sun-icons/gt-clock.icon".
--wnl ]]
------------------------------
End of SUN-Spots Digest
***********************