feldman@umd5.umd.edu (Mark Feldman) (01/27/89)
We have some NeXTs on campus -- we are looking at a few in-house, and the
rest are being purhased for campus faculty. We have found that there are
problems with integrating NeXTs intro our envrionment and I would like to
hear from people at other universities how NeXTs are currently being
distributed, what your plans are for the future, and if you've run into the
same problems that we have.
The NeXT is NeAT, no question about it. I believe that the technical term
is ``slick''. It combines software and hardware into a single, bundled
package that is not available elsewhere.
I'd like to have one on my desk, but for the rest of campus... (I have sent
the follwing comments to NeXT, but I think that putting them on the floor
for discussion will help both us, the users, and NeXT)
The NeXT is a very nice development platform, but there's a
chicken-and-egg problem. We can't advise faculty to write
applications on the NeXT until there are NeXTs for student use.
Untill/unless NeXT meets some of the following concerns, there won't
be NeXTs for student access.
The university computing model requires that users be able to access
and share data easily throughout the campus. When someone is forced
to remove their data (optical drive) when they leave a NeXT, they
are being forced to isolate their data. An optical floppy at home,
left in a backpack or car, or anywhere that there isn't a NeXT is
useless. Because the user's files are not being kept on a central
server, as is done when people use our VAXstations, there is no way
for someone to dial in and access their files. We can back up
servers, but in the NeXT model the user is responsible for the
integrity of their data.
An optical drive-only NeXT isn't desirable in public workstation
rooms -- those rooms where students can access workstations. The
best workstation for public rooms is a workstation that boots off
the network and uses file servers, perhaps keeping its swap space on
a local hard disk. Come to think of it, an optical drive-only
machine isn't very useful anywhere. In most faculty/research
environments, you want speed (hard disk) and a machine that is
stable, not schizophrenic -- we don't need one that changes it's
personality everytime optical disks are swapped.
A NeXT makes a poor file/mail/compute server because it cannot be
used without a MegaPixel Display and it won't power up after a power
loss. Our workstations almost never get turned off (they don't do
much when they're off), so why must we pay extra for a keyboard
power button (a simple on/off switch on the cube must be cheaper)
that doesn't do what we need? Methinks there was too much
``personal computer'' thinking in the design.
The need to share data also requires that the NeXT applications and
data be accessable from non-NeXT workstations. It should be
emphasized to software developers that data written by NeXT
applications should be Unix-style -- readable ASCII files that can
be managed with other Unix utilities. Obviously, there will be a
loss in functionality (there goes that nice interface), but it is
very important that people be able to get to their data.
Source is another important topic with universities, which it seems
NeXT is still side stepping. We don't want the source to IB or any
of the NeXT ``jewels''. We need OS source to insure that we can
integrate the NeXT into our environment and provide quick-fixes to
bugs for which NeXT has yet to release fixes. We have source
licenses from many vendors, and they do not appear to be concerned.
We don't expect to get source for free -- if we go with NeXT, we
will be willing to purchase a source license. Steve Jobs said that
our having source would make it more difficult for NeXT to provide
support. Well, if NeXT doesn't provide source, there's a good
chance that support won't be a problem, as we won't be purchasing
NeXTs.
I don't think that NeXT spent enough time looking at how higher
education uses workstations to facilitate information access and
exchange. If NeXT wait too long before acting, the current NeXT
machine will be outclassed. As it stands now, universities can
purchase workstations with comparable CPU power, albeit without IB,
DPS, and the other bundled software. These other workstations can
be used as file servers and can be purchased diskless.
Another member of the Computer Science Center staff (Brenda Guarnieri -- Hi,
Brenda!) remarked that if NeXT doesn't meet our expectations, NeXT may
become the ``Delorean'' of the computer field. I hope not.
Mark Feldmanjgreely@diplodocus.cis.ohio-state.edu (J Greely) (01/27/89)
In article <4474@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: > The university computing model requires that users be able to access > and share data easily throughout the campus. When someone is forced > to remove their data (optical drive) when they leave a NeXT, they > are being forced to isolate their data. An optical floppy at home, > left in a backpack or car, or anywhere that there isn't a NeXT is > useless. My opinion on the use of optical discs for user files is that it's a warm-fuzzy sort of thing. We'd never be comfortable with it here, and would give students home directories mounted from a generic NFS server. The real use for the opticals is so that users can transport their own material in a more useful form than magtape. The option to use opticals for non-critical files would take the drain off of the fileserver ("If you *really* want a private copy of nethack, keep it on your own disc, kid"). > An optical drive-only NeXT isn't desirable in public workstation > rooms -- those rooms where students can access workstations. The > best workstation for public rooms is a workstation that boots off > the network and uses file servers, perhaps keeping its swap space on > a local hard disk. Booting off the network is supported, although we haven't had time to set it up yet here. This is the method of choice for a lab of student workstations, and NeXT hasn't ignored it. In fact, the release notes mention several enhancements to BOOTP that will make it easier to handle the whole process. My real concern with opticals in a student lab is verification of machines. If J Random Undergrad can reboot from his own disc, I don't want him being trusted by our network for anything. It boils down to the statement that if someone has root access to one optical-equipped NeXT box, he can be root on any others he comes across. This problem doesn't get any mention in the 0.8 release notes. > I don't think that NeXT spent enough time looking at how higher > education uses workstations to facilitate information access and > exchange. I don't think of the NeXT machine as a workstation, at least not in the manner most people think of it. Some people have called it a Sun-killer, which is nonsense. The orientation of the product will put it into places where people would buy Macs, not Suns. I don't believe that any engineering or computer science program will buy them for students. Research, maybe. Liberal arts departments are more likely to use it for students (and how many of *them* can afford it?). Personally, I've begun to think of the NeXT machine as a very bright laser printer. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) The Ohio State University, Department of Computer and Information Sciences
johnl@ima.ima.isc.com (John R. Levine) (01/27/89)
In article <4474@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: > The university computing model requires that users be able to access > and share data easily throughout the campus. When someone is forced > to remove their data (optical drive) when they leave a NeXT, they > are being forced to isolate their data. An optical floppy at home, > left in a backpack or car, or anywhere that there isn't a NeXT is > useless. Because the user's files are not being kept on a central > server, as is done when people use our VAXstations, there is no way > for someone to dial in and access their files. We can back up > servers, but in the NeXT model the user is responsible for the > integrity of their data. If you want to boot your NeXT from the network, store your files centrally, and get to them via NFS, go ahead. It all works now. I don't think anyone seriously expects multiple NeXTs not to be networked any more than you'd expect multiple Suns or Vaxes not to. (The Ethernet is standard, after all.) The optical disk is a perfectly reasonable storage medium for people who don't entirely trust the central server to keep their files around, at the end of a term for example. Also keep in mind the amount of data we're talking about here. Say you have 10,000 students each with one optical disk. That's 2500 gigabytes of storage, a large amount even by modern standards. Given the hardware on the NeXT, we can expect users to have large files full of digitized images and sound. Is it really mission critical to have centralized, backed up copies of 10,000 megabytes of pictures of people's gerbils and voice mail of light bulb jokes? > The need to share data also requires that the NeXT applications and > data be accessable from non-NeXT workstations. It should be > emphasized to software developers that data written by NeXT > applications should be Unix-style -- readable ASCII files that can > be managed with other Unix utilities. Obviously, there will be a > loss in functionality (there goes that nice interface), but it is > very important that people be able to get to their data. Most of the demo programs that NeXT provides seem to keep their data (as opposed to interface builder and screen design stuff) in normal ASCII files. Printer output is postscript. > Source is another important topic with universities, which it seems > NeXT is still side stepping. I was at the developers' camp two weeks ago and at the banquet, Steve Jobs took questions, many of which concerned source code. The opposition to making source available seems to be more pragmatic than theological, they don't want proliferating slightly incompatible versions of everything that would make it harder to interchange applications. He gave the impression that reasoned arguments could persuade them to release parts of the code, particularly the less propritary parts. On the other hand, people do seem to get work done on Macs and PCs without source code, so there's some suspicion that the demands for source code are based as much on Unix tradition as on real need. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something You're never too old to have a happy childhood.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/27/89)
In article <32681@tut.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >I don't think of the NeXT machine as a workstation, at least not in >the manner most people think of it. Some people have called it a >Sun-killer, which is nonsense. The orientation of the product will >put it into places where people would buy Macs, not Suns. The following are University prices. The Sun prices are from the latest Sun price list (let me remind you, this is AFTER discount). For the sake of argument, let's suppose the optical drive is too slow for use as a disk in a typical workstation environment. In order of price: Machine Disk Tape Memory Display Clock CPU FPU Price 3/50 0 4M 19" 15MHz 68020 $4546 NeXT 0 od 8M 17" 25MHz 68030 68882 $6500 3/50 71M 4M 19" 15MHz 68020 $6646 3/50 0 8M 19" 15MHz 68020 $6926 3/60 0 4M 19" 20MHz 68020 68881 $7300 NeXT 330M od 8M 17" 25MHz 68030 68882 $8500 3/50 330M 1/4" 4M 19" 15MHz 68020 $11126 3/50 330M 1/4" 8M 19" 15MHz 68020 $13506 3/60 330M 1/4" 4M 19" 20MHz 68020 68881 $13900 3/60 330M 1/4" 8M 19" 20MHz 68020 68881 $16280 So, an $8500 NeXT machine is the equivalent of a $16000 Sun, even if you don't care about: 25% increase in clock speed. Next step up in processors. A DSP. A good user interface. Lisp. (that's another $4000 from Sun) A word processor. Online dictionary. Online thesaurus. Mathematica (can you say $600 for that Sun?) The od has 256M capacity, versus 60M for 1/4" tape. An easy way to build good user interfaces. Channel processors. Sound. A word processor. A UNIX designed to understand multiprocessors and distributed computing. Now, I'm not saying the NeXT machine doesn't have some gotchas, at the moment. But they are mostly bugs due to the current beta release of the software. And Sun's software STILL has bugs and gotchas, as anyone who does networking on a large scale will be happy to tell you. To say that the NeXT box is not going to compete with Suns for the workstation market is a little strange. I'm not sure what you mean by "orientation"; the NeXT machine does everything Suns do. The fact that it does even more doesn't make it LESS suitable for engineering work, does it? I don't think it's going to kill Suns. But I think Sun is going to have to significantly reduce its prices once the NeXT box is in quantity production. And that will be good even for those of you who are offended by good user interfaces and bundled software :-) :-) :-). Steve -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
paul@phoenix.Princeton.EDU (Paul Lansky) (01/27/89)
In article <32681@tut.cis.ohio-state.edu>, jgreely@diplodocus.cis.ohio-state.edu (J Greely) writes: > In article <4474@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: > > The university computing model requires that users be able to access > > and share data easily throughout the campus. When someone is forced > > to remove their data (optical drive) when they leave a NeXT, they > > are being forced to isolate their data. An optical floppy at home, > > left in a backpack or car, or anywhere that there isn't a NeXT is > > useless. > > My opinion on the use of optical discs for user files is that it's a > warm-fuzzy sort of thing. We'd never be comfortable with it here, and > would give students home directories mounted from a generic NFS server. > The real use for the opticals is so that users can transport their own > material in a more useful form than magtape. The option to use opticals > for non-critical files would take the drain off of the fileserver ("If > you *really* want a private copy of nethack, keep it on your own disc, > kid"). I think it is a seriously short-sighted mistake to simply regard the optical disks as student storage, or portable personal directories, for 'non-critical files', detritus, games, and love letters. It probably does make sense to store most student files on a server. The real beauty of the optical disks is the way in which they enable lots of problems and tasks to be contemplated which were previously dismissed because of the amount of storage they would consume. In processing digital signals, for example, a 75 megabyte file is not particularly large, but I would bet that in most traditional hard-disk academic environments administrators would shrink with horror at the thought of a student occupying 200 megabytes of their online storage. It would be utterly out of the question for a professor to contemplate a course with 20 students, each of whom would need 250 megabytes of disk storage. The issue is that the ways of thinking about disk storage and computing task have become petrified because of the hard constraints on these resources. Now that this storage is available lots of signal processing and graphical applications, for example, which need large amounts of disk storage can start to filter down to the student level, whereas previously they were mainly the purview of researchers, professors and graduate students. The marriage of this capability with a machine which is capable of signal and image processing is a brilliant stroke. The possiblility of almost infinite, inexpensive, disk storage, perhaps a bit slow for a year or two, creates a really new dimension in computing, educational computing in particular. Whether you run the system from an internal hard disk, from a server (I suspect the best way is NOT from an optical disk), or whatever, is a problem that doesn't seem all that difficult to solve. But any administrators who can't see the fact that this configuration opens a new door, are short-changing their constituents and ought to go back to school themselves.
feldman@umd5.umd.edu (Mark Feldman) (01/28/89)
In article <32681@tut.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: > >Booting off the network is supported, although we haven't had time >to set it up yet here. This is the method of choice for a lab of >student workstations, and NeXT hasn't ignored it. In fact, the >release notes mention several enhancements to BOOTP that will make >it easier to handle the whole process. Ok, but you can't use a NeXT as the BOOTP/NFS server, unless you are willing to pay someone to make sure that it is on all the time. > My real concern with opticals in a student lab is verification of >machines. If J Random Undergrad can reboot from his own disc, I >don't want him being trusted by our network for anything. It boils >down to the statement that if someone has root access to one >optical-equipped NeXT box, he can be root on any others he comes >across. This problem doesn't get any mention in the 0.8 release >notes. There is no way to prevent a user from booting off the optical or prevent them from booting in single-user mode. This means that anyone can become root. Prventing someone from going root helps security somewhat (anything that you can throw in their path is helpful), but not too much as any PC user can go ``root''. What we need is authentication, so we decide to put MIT Project Athena's Kerberos authentication systems on the NeXT. Uh oh, no OS source. We're stuck. In article <3231@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes: > >Given >the hardware on the NeXT, we can expect users to have large files full of >digitized images and sound. Is it really mission critical to have >centralized, backed up copies of 10,000 megabytes of pictures of people's >gerbils and voice mail of light bulb jokes? Good point! Now if only the person sitting at the NeXT could manipulate the optical without having to become root. And while we're sitting in front of the NeXT, it would be nice if the user at the NeXT could prevent other users from popping up windows and making sounds, again, without becoming root. >I was at the developers' camp two weeks ago and at the banquet, Steve Jobs >took questions, many of which concerned source code. The opposition to >making source available seems to be more pragmatic than theological, they >don't want proliferating slightly incompatible versions of everything that >would make it harder to interchange applications. He gave the impression >that reasoned arguments could persuade them to release parts of the code, >particularly the less propritary parts. I was there, too. Did you have the lasagna or turkey (or was it chicken?)? I had the turkey, and as a matter of fact, I was the first person in the group to ask about source. I still think that NeXT is side stepping the issue. For many people, the decision to purchase NeXTs is resting on availability of operating system (not application) source. As I said in my previous posting, we have source licenses from other vendors. We would prefer that the vendors provide all of the support -- quick fixes for bugs and the extensibility needed to integrate their systems into our environmnet, but the vendors cannot provide these services to the extent that we would like, so we have source. Has this cause our other vendors headaches? No. We've been able to do our thing and help them in the process by pointing out (in detail) OS bugs. If the Internet virus of months back happened now and was a NeXT virus, we would be forced to disable much of the networking software or turn our NeXTs off until receiving updates from NeXT. As it happened, our systems staff had the necessary source and quiclky put out fixed software. We are a networked campus with many network services, including NTP (network time protocol) time. We have expertise in both UNIX and NTP -- the UNIX NTP daemon was written here. When the people who wrote the UNIX NTP daemon tried to port it to the NeXT, it hung. Some nasty Mach/networking bug causes the NeXT to forget all of its interrupts or go into a very tight kernel loop. Whateve the case, the NeXT hangs. Can we fix it? Can we find the OS bug and report it to NeXT (helping them!)? No. We don't have the necessary source. > On the other hand, people do seem >to get work done on Macs and PCs without source code, so there's some >suspicion that the demands for source code are based as much on Unix >tradition as on real need. Most PC applications make very little use of DOS, as DOS does not provide many useful services. Many (most?) PC applications talk directly to the harware (keyboard, screen, speaker), so having DOS source doesn't do much for you. Many applications do make use of BIOS routines and the source to BIOS is available. The Mac provides more services and a more structured environment, but it is still much less complicated than a multi-tasking, multi-user workstation (e.g., the NeXT). NeXT must commit itself now to providing what the university community -- its target market -- wants. I have trouble believing that our NeXT concerns are very different from those at any other university, even if I sometimes have trouble putting them into words. He who hesitates is lost, or, in this cae, skipped over at purchasing time. Mark
deraadt@xenlink.UUCP (Theo A. DeRaadt) (01/28/89)
I can just see a student bring in his optical disk, put it in, mount it, and run a setuid program on it. Now he's root. Fun stuff. <tdr.
deraadt@xenlink.UUCP (Theo A. DeRaadt) (01/28/89)
In article <3231@ima.ima.isc.com>, johnl@ima.ima.isc.com (John R. Levine) writes: > I was at the developers' camp two weeks ago and at the banquet, Steve Jobs > took questions, many of which concerned source code. The opposition to > making source available seems to be more pragmatic than theological, they > don't want proliferating slightly incompatible versions of everything that > would make it harder to interchange applications. He gave the impression > that reasoned arguments could persuade them to release parts of the code, > particularly the less propritary parts. On the other hand, people do seem > to get work done on Macs and PCs without source code, so there's some ^^^^^^^^^^^^^ > suspicion that the demands for source code are based as much on Unix > tradition as on real need. That's some comparison. Yes, people write hacks and hacks and hacks and hacks to get by bugs IN the operating system, and next release it breaks. Just look at any program that was written for the original Mac on a MacII, programs that do anything *really neat* ussually break. Did you know that every Sun comes with source to the windowing environment on it? We hacked it ourselves to add full-color backdrops and such, but how many others have? Having source made it so much easier - we had a starting point and we could see *exactly* how things were done from the bottom up. Hate to compare this to Sun's, but did you ever really try to read some of those manuals? Yet, you go into the source, and it's obvious. <tdr.
asd@mentor.cc.purdue.edu (Kareth) (01/28/89)
In article <400@garcon.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu.UUCP (Steve Dorner) writes: >The following are University prices. The Sun prices are from the latest >Sun price list (let me remind you, this is AFTER discount). For the >sake of argument, let's suppose the optical drive is too slow for use >as a disk in a typical workstation environment. I'd definitely would want to boot off a device 5-6 times slower than a hard drive. >NeXT 0 od 8M 17" 25MHz 68030 68882 $6500 ^^^^^ >NeXT 330M od 8M 17" 25MHz 68030 68882 $8500 ^^^^^ Don't forget to tack on the "hidden" charges like support. A NeXT rep at a show here said whoever sold it would have to add on 2-3% or so for the money they had to dish out to be able to sell the machines (training, etc). Not that an extra 2-3% is all that much. Was any of those Sun prices with color monitors? Those color monitors aren't cheap. >Now, I'm not saying the NeXT machine doesn't have some gotchas, at the >moment. But they are mostly bugs due to the current beta release of >the software. And Sun's software STILL has bugs and gotchas, as anyone >who does networking on a large scale will be happy to tell you. And NeXT's software won't in the near future? When your dealing with the amount of code that goes into OS's, bugs are a fact of life. >To say that the NeXT box is not going to compete with Suns for the >workstation market is a little strange. I'm not sure what you mean by >"orientation"; the NeXT machine does everything Suns do. The fact that >it does even more doesn't make it LESS suitable for engineering work, >does it? True, but remember ONLY at school! I wonder what will happen when some student graduates with his cube and no longer has support for it. But then again, how many kids have $10+ grand to shell out for a machine they can effectively use. (cube, 330 hard, printer). >I don't think it's going to kill Suns. But I think Sun is going to have >to significantly reduce its prices once the NeXT box is in quantity production. >And that will be good even for those of you who are offended by good >user interfaces and bundled software :-) :-) :-). No doubt! Now if only regular folks could buy it, and not just folks in school, and usually only the staff. It could be a big hit if anybody who could buy a Mac SE (loaded) or a II(slightly less loaded), could buy a NeXT. kareth.
steve@polyslo.CalPoly.EDU (Steve DeJarnett) (01/28/89)
In article <1038@mentor.cc.purdue.edu> asd@mentor.cc.purdue.edu (Kareth) writes: >Now if only regular folks could buy it, and not just folks in >school, and usually only the staff. It could be a big hit if anybody who >could buy a Mac SE (loaded) or a II(slightly less loaded), could buy a NeXT. > >kareth. The NeXT people were here at Cal Poly yesterday and they said they were trying to work out something like Apple has where they let you pay for your system over X years. This MIGHT put a baseline NeXT in a more student's price range (~$1800/year for 4-5 years). Certainly not a lot more students, but if they could get the price down with more mass production (in time), then it could be affordable. Until then, head for the nearest campus with a NeXT lab and enroll... ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
tytso@athena.mit.edu (Theodore Y. Tso) (01/28/89)
In article <4476@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes: >There is no way to prevent a user from booting off the optical or prevent >them from booting in single-user mode. This means that anyone can become >root. Prventing someone from going root helps security somewhat (anything >that you can throw in their path is helpful), but not too much as any PC user >can go ``root''. What we need is authentication, so we decide to put MIT >Project Athena's Kerberos authentication systems on the NeXT. Uh oh, no OS >source. We're stuck. We at MIT have managed to get Kerberos up and running on the NeXT. Since Berkeley has released the networking code, it is possible to get a Kerberized rlogin, rsh, etc. This will also allow you not to be screwed over by Sun's yellow pages. MIT Project Athena's Hesiod (a general-purpose name service layered on top of named --- our answer to yellow pages) also more or less dropped right in. Kerberos and Hesiod are available by anonymous FTP from ATHENA-DIST.MIT.EDU. >In article <3231@ima.ima.isc.com> johnl@ima.UUCP (John R. Levine) writes: > >Good point! Now if only the person sitting at the NeXT could manipulate the >optical without having to become root. And while we're sitting in front of >the NeXT, it would be nice if the user at the NeXT could prevent other users >from popping up windows and making sounds, again, without becoming root. We've also gotten MIT Project Athena's "attach" program running on the NeXT. It uses Kerberos and Hesiod (although neither is strictly necessary), it allows users to mount and umount NFS file systems by commands such as "attach games", where hesiod expands "games" to "NFS /mit/lockers/games m4-035-w.mit.edu w /mit/games", which attach interprets and Does The Right Thing with it. I will be shortly extending attach also deal with UFS file systems, such as the optical disk. I will also be shortly (tonight) be extending attach to restrict what users can mount and where they can mount things. Attach has not been exported by Project Athena yet; but if anybody is interested, let me know. >If the Internet virus of months back happened now and was a NeXT virus, we >would be forced to disable much of the networking software or turn our NeXTs >off until receiving updates from NeXT. As it happened, our systems staff >had the necessary source and quiclky put out fixed software. We are a >networked campus with many network services, including NTP (network time >protocol) time. We have expertise in both UNIX and NTP -- the UNIX NTP >daemon was written here. When the people who wrote the UNIX NTP daemon >tried to port it to the NeXT, it hung. Some nasty Mach/networking bug >causes the NeXT to forget all of its interrupts or go into a very tight >kernel loop. Whateve the case, the NeXT hangs. Can we fix it? Can we find >the OS bug and report it to NeXT (helping them!)? No. We don't have the >necessary source. Actually, when I tried running ntpd, not only did it managed to crash the system, it stomped all over the (I assume) non-volitile memory where the boot preferences are stored. Fairly impressive bug. I seriously hope that the NeXT people are paying attention, and that the higher management (like Jobs) actually reads some of this. Believe it or not, Apple may actually be more reasonable with A/UX sources than NeXT is. NeXT can ill-afford to alienate the developers by being so obnoxious on the source code issue..... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
mrc@Tomobiki-Cho.acs.washington.edu (Mark Crispin) (01/29/89)
In article <33@xenlink.UUCP> deraadt@xenlink.UUCP (Theo A. DeRaadt) writes: >I can just see a student bring in his optical disk, put it in, mount it, >and run a setuid program on it. Now he's root. Fun stuff. What difference does that make? If you can mount your OD while having the SCSI filesystem booted, then you needed root to run /etc/mount. Of course, you could have booted the NeXT from the OD (since it's *your* OD, presumably you know how to become root on it) and then mounted the SCSI filesystem. You don't even need an OD. Just boot the system standalone and you're root. It's an utter fallacy to believe that an individual with physical access to a NeXT (or any other computer) can't trivially become root on that machine. The problem is these cretins who believe in "trusted hosts" and that being root on some workstation entitles one to root elsewhere.
jgreely@diplodocus.cis.ohio-state.edu (J Greely) (01/29/89)
In article <669@blake.acs.washington.edu> mrc@Tomobiki-Cho.UUCP (Mark Crispin) writes: >It's an utter fallacy to believe that an individual with physical access >to a NeXT (or any other computer) can't trivially become root on that >machine. This is *mostly* true at the moment, and is due to the current design of most workstations. It is not, however, a universal truth, and should not be treated as such. After much pounding, Sun has finally released a PROM that purports to disallow low-level mucking, and has added the option to force the use of a password to boot single-user in SunOS 4.0. We don't have the combination here yet, but I'd love to attack them when we do. I have a feeling it won't be quite so trivial to exploit that set of holes. We'll have to use the *other* holes. >The problem is these cretins who believe in "trusted hosts" and that >being root on some workstation entitles one to root elsewhere. Who cares about trusting root? Bluntly, I can do almost as much damage with a machine that is trusted for non-root access only. Is it trusted for rlogin? rsh? rexd? yp? All known potential problems, all vulnerable to one person getting root on a networked workstation. Cretins, Mr. Crispin? Only if we believe that not trusting root from a workstation will solve our security problems. From any one of our 250+ workstations, I can remove the files of every user on our network. Not one of those workstations is trusted by any other as root. Sure, trusting root would make it easier for an unscrupulous undergrad (or an alliterative administrator, for that matter) to cause damage, but it's foolish (cretinous?) to imply that the only way to abuse a network is through global root access. But I've got more concerns than trashing user file systems. I'm not sure that Kerberos is the way to go, or as useful as they claim. Anyone remember the recent hate mail incident involving Nancy Gould? The mail was sent from some anonymous person who'd logged in as root at a public workstation at MIT and telnet'd to the SMTP port of her machine. Guess you don't need to be authenticated to make use of worldwide network services. Makes my little heart just *glow* with anticipation. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely) The Ohio State University, Department of Computer and Information Sciences
jon@athena.mit.edu (Jon Rochlis) (01/29/89)
>But I've got more concerns than trashing user file systems. I'm >not sure that Kerberos is the way to go, or as useful as they >claim. Anyone remember the recent hate mail incident involving >Nancy Gould? The mail was sent from some anonymous person who'd >logged in as root at a public workstation at MIT and telnet'd to >the SMTP port of her machine. Guess you don't need to be >authenticated to make use of worldwide network services. Makes my >little heart just *glow* with anticipation. Face it, the lower level protocols (IP/TCP) don't have authentication in them and I'm not holding my breath for something like Visa to catch on big. You must assume anybody can gain access to the network. The fault in the hate mail case you mention is not with allowing unathenticated access to the network (there are dozens of unprotected terminal servers out there and even more accounts with trivial guessable passwords as the recent LLNL indicdents demonstrated. The problem is that SMTP does no real authentication. If you had a Kerberos-based (or other reasonable authentication system) SMTP then you'd be in business (except of course for getting mail from the majority over sites out there that aren't playing the game). Mail is a tought one in general. If you're interested in how you might go about doing authenticated mail in a reasonable way take a look at RFC1040. -- Jon
kean@mist.cs.orst.edu (Kean Stump) (01/29/89)
In article <1038@mentor.cc.purdue.edu> asd@mentor.cc.purdue.edu (Kareth) writes: >True, but remember ONLY at school! I wonder what will happen when some >student graduates with his cube and no longer has support for it. But then >again, how many kids have $10+ grand to shell out for a machine they can >effectively use. (cube, 330 hard, printer). > It is written into the contract here that if I leave my position at the University, the University Computer Center is still obligated to honor the remainder of the warrantee period and to service the cube should it ever break. This is a problem if I move to the East Coast, since shipping the cube back to Oregon would be expensive, but service is guaranteed for a reasonably long period, five years in my case (I think!) kean ------------------------------------------------------------------------------- Oregon State University Kean Stump Department of Computer Science kean@cs.orst.edu Corvallis, Oregon {tektronix,hp-pcd}!orstcs!kean "OSU CS isn't my employer, so don't take me seriously" -------------------------------------------------------------------------------
mrc@Tomobiki-Cho.acs.washington.edu (Mark Crispin) (01/30/89)
OK, since you didn't understand last time, let me put it another way: If you set up external access via the r* tools, or use NFS, you don't have any security on your system worth a damn. This has been repeatedly and convincingly demonstrated. If you allow security data (including passwords) to be transmitted in plaintext then you don't have any security on your system worth a damn. If you allow security data (including passwords) to be available in any form (even if encrypted) to processes which do not have an absolute need for this data then you don't have any security on your system worth a damn. File write protections on most operating systems (including Unix) are useful mostly to prevent accidental overwriting or destruction of system files and do not protect against intentional overwriting or destruction. File read protections on most operating systems (including Unix) are useful mostly to prevent accidental reading of private files and do not protect against intentional reading. The vast majority of Unix tools were put together without system security implications in mind. In general, the tools were developed by expert users intending these tools to be used by other expert users with non-hostile intent, e.g. the use of gets() in many tools. Unix is not a secure operating system, particularly with the r* and NFS networking facilities enabled. In many ways, it is less secure than the completely unprotected ITS operating system, because the half-hearted attempts at security it does make offers incentive to crackers to show off. Furthermore, it introduces a false sense of security. It is indeed cretinous to assume that your Unix system is secure. Keeping these things in mind, it is possible to configure your Unix so that your typical cracker will go away quite frustrated and bother someone else. Such configurations may involve some inconvenience; as Brian Reid noted, "system programmer convenience is often the antithesis of security." I feel that buggering a workstation to deny its user control over it is a step in the wrong direction.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/30/89)
In article <1038@mentor.cc.purdue.edu> asd@mentor.cc.purdue.edu (Kareth) writes, in reply to my Sun/NeXT price comparison: >Don't forget to tack on the "hidden" charges like support. A NeXT rep at a >show here said whoever sold it would have to add on 2-3% or so for the money >they had to dish out to be able to sell the machines (training, etc). Not >that an extra 2-3% is all that much. Ok. Add $255 to the $8500 NeXT box, $195 to the $6500 box (that's 3%). Nothing much changes. > Was any of those Sun prices with color >monitors? Those color monitors aren't cheap. Nope. 19" Monochrome; the Sun monitors have more pixels, but not even 2 bits of grayscale. I think the NeXT screen is better, but I suspect that's a personal issue; some people would probably prefer the larger mono screen. -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
ronc@fai.UUCP (Ronald O. Christian) (02/01/89)
In article <669@blake.acs.washington.edu> mrc@Tomobiki-Cho.UUCP (Mark Crispin) writes: >The problem is these cretins who believe in "trusted hosts" and that >being root on some workstation entitles one to root elsewhere. True, but I wonder: Should that include access to backup devices on other machines? For instance, on our equipment (non-NeXt) I can't do an rrestore or rdump because if I do it as root, I get a permission denied on reading the remote device, and if I do it as a regular user, I get a permission denied on the chown. A loser either way. Do the NeXt network backup commands handle this elegently without resorting to "trusted hosts"? BTW, yesterday I got to play with a $2000, 100 dot-per-inch X terminal, which can be used with a standard 386 PC and is available to non-students NOW. The NeXt is nice, (I saw one at MacWorld) but if it doesn't become available soon, the world is going to pass it by... Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!fai!ronc -or- ronc@fai.com