gillies@p.cs.uiuc.edu (08/10/89)
Actually, I've been thinking a little bit about NeXT security. If your site can guarantee that nobody boots a rogue disk from another college, then you should be secure. The basic security measure is the optical disk, WHICH CANNOT BE READ OR WRITTEN BY ANY OTHER COMPUTER OR DISK DRIVE. Thus, if you can keep students from using non-standard optical disks (e.g. hacked up by a student who has root access to his NeXT machine at home), then you can control network access and a host of other things. Now if NeXT would only provide a way to maintain this security.
jgreely@oz.cis.ohio-state.edu (J Greely) (08/12/89)
In article <116900006@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >Actually, I've been thinking a little bit about NeXT security. There are times it's kept me awake nights... >If your site can guarantee that nobody boots a rogue disk from another >college, then you should be secure. Uhh, I can't guarantee that no one boots a disk from another *department*. And, frankly, until 1.0 comes out, it doesn't matter where their disk comes from. Under 0.9, possession of a bootable OD is equivalent to root access on any NeXT you can physically reach. This is fixed in 1.0 ("real soon now"). >The basic security measure is the optical disk, WHICH CANNOT BE READ >OR WRITTEN BY ANY OTHER COMPUTER OR DISK DRIVE. The basic security *problem* is the OD. Cheap, portable disks large enough to hold a bootable Unix. And don't rely on the obscurity of the media to protect you. That's fuzzy thinking, considering how fast CDs have taken over the audio market. >Now if NeXT would only provide a way to maintain this security. "Fixed in 1.0". -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
epsilon@wet.UUCP (Eric P. Scott) (08/14/89)
In article <JGREELY.89Aug11220105@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: > > Under 0.9, possession of a bootable OD >is equivalent to root access on any NeXT you can physically reach. >This is fixed in 1.0 ("real soon now"). Our campus of "Enormous State University" has a required Operating Systems class for most Computer Science majors that includes making bootable systems as a graded project. This isn't a hypothetical--this is on the level. The class currently uses Convergent Technologies Miniframes, which are no longer supported by their manufacturer. What's an affordable replacement that also uses 68000-series CPUs? I take it NeXT will no longer be a qualified bid. -=EPS=-
jgreely@oz.cis.ohio-state.edu (J Greely) (08/14/89)
In article <416@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >Our campus of "Enormous State University" has a required >Operating Systems class for most Computer Science majors that >includes making bootable systems as a graded project. First things first. Do you mean writing an OS, such as Xinu, or does "making bootable systems" mean something different? Not sure what you want, so I can't tell you exactly what I think of using a NeXT for it. > What's an affordable replacement that also uses 68000-series CPUs? >I take it NeXT will no longer be a qualified bid. Deep, *deep* sigh. No, at least not the way you're thinking. Am I the only person who hears these things, or is my writing style really that unclear? I said, "Under 0.9, possession of a bootable OD is equivalent to root access on *any* NeXT you can physically reach" (emphasis added to stress the meaningful part). That's different from having root access on *selected* NeXTs. The ROM changes in 1.0 allow the administrator of a machine to prevent unauthorized individuals from doing interesting things like changing the boot device (which is actually one of the least interesting things you can do from the monitor). They do not disable booting from OD, they allow you to control it. "It's okay. Kinda reminds me of a Benihana in Rangoon that does Cub Scouts at table-side." "Yeah, I been there..." -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
z8my@vax5.CIT.CORNELL.EDU (08/15/89)
In article <JGREELY.89Aug11220105@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >In article <116900006@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>Actually, I've been thinking a little bit about NeXT security. > >There are times it's kept me awake nights... >The basic security *problem* is the OD. Cheap, portable disks large >enough to hold a bootable Unix. And don't rely on the obscurity of >the media to protect you. That's fuzzy thinking, considering how fast >CDs have taken over the audio market. I've heard a lot of talk about "security". But it seems to me that this concert is over rated. Consider that personal computers a'la IBM PCs and Macs can be cheaply added to a UNIX style network. Who needs an entire Unix kernal? If you want to make mischief, all you need is a compiler and the opportunity to download one of the several public-domain and freely available tcp/ip packages, like KA9Q, NCSA_Telnet, PCIP, CITI-MACIP... Sam Paik d65y@vax5.cit.cornell.edu p.s. This isn't to say that system security isn't important. I like my files to remain, after my and your mistakes, and malice too...
epsilon@wet.UUCP (Eric P. Scott) (08/16/89)
In article <JGREELY.89Aug14104814@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >In article <416@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >>Our campus of "Enormous State University" has a required >>Operating Systems class for most Computer Science majors that >>includes making bootable systems as a graded project. > >First things first. Do you mean writing an OS, such as Xinu, or does >"making bootable systems" mean something different? Not sure what you >want, so I can't tell you exactly what I think of using a NeXT for it. Writing *small* memory-only systems. Let's say, no I/O other than a timer and a serial port. Maybe two serial ports and a round-robin scheduler. Very basic stuff. File system implementation is left to the graduate level. > The ROM changes in 1.0 allow >the administrator of a machine to prevent unauthorized individuals >from doing interesting things like changing the boot device (which is >actually one of the least interesting things you can do from the >monitor). They do not disable booting from OD, they allow you to >control it. Giving our users root access is just not a substantial risk. If anyone can "lock" an otherwise accessible cube so that no one else can use it ... that is a SERIOUS threat. It's near- impossible to trace, and could be difficult to correct. Per-system passwords don't work for us, only per-user do, and not always that well. Computer "security" measures invariably cause more inconvenience to legitimate users than they "protect" anything. We use physical (usually non-electronic) approaches. #1 concern is theft--we've had a lot of hardware "walk." There is nothing special about computers. They are pieces of laboratory equipment, can be secured as any other laboratory equipment, and abusers can be disciplined as in any other laboratory environment. -=EPS=-
eht@f.word.cs.cmu.edu (Eric Thayer) (08/16/89)
In article <420@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >In article <JGREELY.89Aug14104814@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >>In article <416@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >> The ROM changes in 1.0 allow >>the administrator of a machine to prevent unauthorized individuals >>from doing interesting things like changing the boot device (which is >>actually one of the least interesting things you can do from the >>monitor). They do not disable booting from OD, they allow you to >>control it. > >Giving our users root access is just not a substantial risk. If >anyone can "lock" an otherwise accessible cube so that no one >else can use it ... that is a SERIOUS threat. It's near- >impossible to trace, and could be difficult to correct. It's not clear to me who the users of your NeXT's will be but, perhaps you could give the machines a password and let the people in the class know what it is. Then, give a stiff penalty for getting caught leaking the password or changing the password on a system. The password protection scheme is not too obtrusive (but I don't know peoples' thresholds of obtrusiveness either :-) ). It could be a short but obscure password because to brute force the password, someone would have to rig up an automated way of getting input data to the console (although /dev/ttya can be configured as an alternate console, it is possible to require a password to do that). I can see however, that it would be tempting for a student who had not completed an assignment before an impending deadline to waste all (or such a percentage that it locked out a significant fraction of the class) the machines in the lab. -- Eric H. Thayer School of Computer Science, Carnegie Mellon (412) 268-7679 5000 Forbes Ave, Pittsburgh, PA 15213
myerst@yvax.byu.edu (08/23/89)
>The majority of posters addressing security have been talking about booting >from the OD, but no one has mentioned the holes in NetInfo. I agree that as far as security is concerned, the use of ODs should be the least of our worries. Any moron who has access to a NeXT keyboard can put the machine into single user mode with two keystrokes, vipw the /etc/passwd file, and/or modify NetInfo to his liking. This can be done if booting off of an OD or SCSI disk, it doesn't matter. If it is security you want, a locked door is your best bet. ++Tim UNIX and security are mutually exclusive. :-)