[comp.sys.next] Diskless NeXT's??

jal@ee.rochester.edu (John Lefor) (08/09/89)

We  have a student laboratory filled with some NeXT's that will be
connected to our departmental ethernet.  We are planning on having
three of the NeXT's run diskless and have a 660Mb in the fourth
to provide disk services.

It occurs to us that in this environment, a student could insert 
their own optical disk and defeat some of the controls we have
instituted.  

Thus the question - is it possible to defeat the optical disk for 
purposes of system boot without completely disabling the optical?
If this is not possible now, would NeXT consider such an option i nthe
near future.

Universities want to know.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I program ... therefore I am.

John Lefor    	University of Rochester		Dept of E. Engineering
716-275-8265	jal@ee.rochester.edu		uunet!ur-valhalla!jal

bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/09/89)

In article <1989Aug8.192101.3060@ee.rochester.edu> jal@ee.rochester.edu (John Lefor) writes:
   We  have a student laboratory filled with some NeXT's 

That may have been your first mistake :-)

   Thus the question - is it possible to defeat the optical disk for
   purposes of system boot without completely disabling the optical?

Apparently not.

   If this is not possible now, would NeXT consider such an option in
   the near future.  Universities want to know.

Depends upon what you mean by "near future."  We've been asking this
sort of optical/security question for over a year now, with no
satisfactory answer.  At this point, NeXT is so busy trying to achieve
its own agenda in a measurable timeframe that it doesn't seem to have
many resources left to spend making the cube useful to universities.

jgreely@oz.cis.ohio-state.edu (J Greely) (08/09/89)

In article <1989Aug8.192101.3060@ee.rochester.edu> jal@ee.rochester.edu
 (John Lefor) writes:
[networked NeXTs, running diskless]
>It occurs to us that in this environment, a student could insert 
>their own optical disk and defeat some of the controls we have
>instituted.  

Under 0.9, that is true.  There's not much you can do to prevent these
problems right now.

>Thus the question - is it possible to defeat the optical disk for 
>purposes of system boot without completely disabling the optical?

Not yet.  Under 1.0, you will be able to prevent users from mucking
about in the ROM monitor, which, in the absence of unforseen problems,
should suffice to make ODs safe to use on networked machines.  The
changes were done a while ago, and I haven't heard of any problems
with them.  Of course, I haven't had a chance to beat on it myself,
but that should come soon (my latest release quote, as of about an
hour ago, is "early September").


				"Fixed in 1.0"
-=-
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)

UH2@PSUVM.BITNET (Lee Sailer) (08/10/89)

In article <1989Aug8.192101.3060@ee.rochester.edu>, jal@ee.rochester.edu (John Lefor) says:
>
>Thus the question - is it possible to defeat the optical disk for
>purposes of system boot without completely disabling the optical?
>If this is not possible now, would NeXT consider such an option i nthe
>near future.
>

   I don't have  a NeXT, so this is just an idea:

To boot from the floptical, a user has to have the "system" on it, right?
To build a lab of NeXTs (booting from a file server) but at the same time
stop hordes of students from booting from their own flopties, a partial
(very partial!) solution would be to not give students the "system".

1.  The average student -- wouldn't take the time to figure out that
he or she could copy the relevant system files from the server and
construct a bootable disk.

2.  The dedicated hacker -- could construct a bootable flopty, or
simply obtain one elsewhere, but is by this time mature enough not to
be malicious.

3.  The malicious hacker -- will figure out a way to beat the system,
anyway.

In short, the thrust of this simple, though only parital solution is to
throw a few organizational hurdles in front of the unauthorized system
booter that will stop the ignorant meddler, plus throw a heavy dose
of socialization at those who will eventually acquire the technical skills
so that by the time they figure out how to be an unathorized booter they
know better.

Tangent--these same students could, at most schools, easily steal any and
all faculty mail (paper--from faculty mail boxes).  They don't.  Because,
at least in part, of socialization. We need the same community rules with
regard to tampering with computer systems.

                                          lee

mcdonald@uxe.cso.uiuc.edu (08/11/89)

>Instead of trashing the "world on a disk" concept NeXT could implement an
>operating system in which the system files would remain in the machine and
>files needed to customize and run the system would be on the users floptical.
>This would allow Joe user to be king of his environment, and would let the
>workstation retain enough integrity to be a functioning, secure member of the
>network. Whenever Joe NMIs however, it would only dump his customizations, the
>system would remain intact. Thus Joe gets all the power of being standalone
>yet has access to the network.

I don't understand this. I get my NeXt in a box. I take it out and
plug it in. I install the operating system, making myself root. What
do you want to prohibit me from doing? I paid for a machine to do
my bidding. Are you proposing that machine come from the factory set
so the purchaser can't become root, or that root be unable to do
certain things? If you can't do certain things, like write to
certain disk blocks (where the security code is) what happens if
one of those blocks get corrupted and some important feature of the
machine is disabled?  How does it get fixed if I can't boot from
the optical? This whole scheme sounds impractical.

Or are you proposing some scheme such as having a serial number
permanently in the machine so that to boot as root from the
optical you have to know the number? This is of course OK in itself,
so long as the operating system is bundled with the hardware,
but is rendered objectionable as it could lead to other copy
protected software. I would not buy such a machine, but others
might.

Doug McDonald

johnl@esegue.uucp (John Levine) (08/11/89)

In article <1989Aug8.192101.3060@ee.rochester.edu>, jal@ee.rochester.edu (John Lefor) says:
>Thus the question - is it possible to defeat the optical disk for
>purposes of system boot without completely disabling the optical?

You can set up a NeXT to boot from the optical, from the SCSI, or from
the Ethernet.  It's a parameter you set by typing at the ROM monitor.  You
can if you want boot from the net even if you have an optical and a SCSI disk.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
{ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something
Massachusetts has 64 licensed drivers who are over 100 years old.  -The Globe

jgreely@oz.cis.ohio-state.edu (J Greely) (08/12/89)

In article <245300019@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>I don't understand this. I get my NeXt in a box. I take it out and
>plug it in. I install the operating system, making myself root. What
>do you want to prohibit me from doing? 

Nothing.  The current discussion has absolutely nothing to do with
personal machines.  We're talking about university lab environments.
I don't much care what you do with your NeXT, but when you use *mine*
(translation: department facility), you will not be permitted to boot
the machine from your own disk.  Period.  If you have a carefully
customized environment on your OD, that's too bad.  $10 says you're
not using my sendmail.cf, uid assignment scheme, subnet mask, YP
domain, NFS mounts, network routing, /bin/mail, /etc/rc, etc.

-=-
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)

carlos@tybalt.caltech.edu (Carlos Salinas) (08/14/89)

In article <245300019@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>
>
>>Instead of trashing the "world on a disk" concept NeXT could implement an
>>operating system in which the system files would remain in the machine and
>>files needed to customize and run the system would be on the users floptical.
>>This would allow Joe user to be king of his environment, and would let the
>>workstation retain enough integrity to be a functioning, secure member of the
>>network. Whenever Joe NMIs however, it would only dump his customizations, the
>>system would remain intact. Thus Joe gets all the power of being standalone
>>yet has access to the network.
>
>I don't understand this. I get my NeXt in a box. I take it out and
>plug it in. I install the operating system, making myself root. What
>do you want to prohibit me from doing? I paid for a machine to do
>my bidding. Are you proposing that machine come from the factory set
>so the purchaser can't become root, or that root be unable to do
>certain things? If you can't do certain things, like write to
>
> Doug McDonald

All I'm proposing is that the NeXT have a shared management operating system.
The management of core system files, ie files common to all user environments,
including files for maintaining the network (protocols, device specs and such)
and provision of services such as servers, printers, and the world (Internet) 
would be the responsibility of a supersuperuser. Files specific to a particular
user environment, including page and swap files, would be the responsibility
of the superuser (a superuser could be anyone wielding a disk). Superusers
could maintain noprivileged (diskless users) user files on their disk. Super-
users wielding disks could "bootin" to a NeXT and wreak total havoc on their
private disk without affecting the integrity of the network or system.

This division of management would decrease the time to "boot" (actually the
NeXT could maintain several "booted" user environments transparent to each
other. A booted environment is simply the operating system with an interface,
you could login in to a "booted" environment, but you couldn't login to an
unbooted one), increase the feasibility of servers, allow a secure network,
and retain the traditional multi-user non-privileged environment while allow-
ing anyone with a disk (optical, rugged SCSI harddrive or otherwise) to be
superuser.

Carlos Salinas
Random Undergrad Caltech

gillies@p.cs.uiuc.edu (08/14/89)

I think perhaps the NeXT machine needs a keyswitch that simultaneously
locks the case shut and forces it to boot from the hard disk (or
network).  In this way, you could prevent students from hacking on the
network using a public NeXT box.

On the other hand, I believe computer nets should be robust enough to
prevent students from doing dangerous hacking.  I once wrote TCP
software for a PC connected to the ARPAnet, and there was no problem.
However, one day my officemate crashed 3 vaxes using the PC's tftp.
Berkeley UNIX was just too flakey and non-robust (the TCP couldn't
handle zero-length packet options).

It seems like only MIT and Xerox care enough to put an authentication
protocol on their sensitive network services.  Maybe other sites should
start to care.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies

fqoj@vax5.CIT.CORNELL.EDU (08/17/89)

In article <JGREELY.89Aug11214350@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes:
>In article <245300019@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>>I don't understand this. I get my NeXt in a box. I take it out and
>>plug it in. I install the operating system, making myself root. What
>>do you want to prohibit me from doing? 
>
>Nothing.  The current discussion has absolutely nothing to do with
>personal machines.  We're talking about university lab environments.
>I don't much care what you do with your NeXT, but when you use *mine*
>(translation: department facility), you will not be permitted to boot
>the machine from your own disk.  Period.  If you have a carefully
>customized environment on your OD, that's too bad.  $10 says you're
>not using my sendmail.cf, uid assignment scheme, subnet mask, YP
>domain, NFS mounts, network routing, /bin/mail, /etc/rc, etc.
>
>-=-
     I guess I don't understand all the furor here. J. Greely is
     right on the mark when he says your machine is your own. On
     "our" network, as long as that little black wire is attached,
     you belong to us and are bound by our rules. But I think we
     can make things as "secure" as they're going to be with the following:
 
     The cubes boot diskless of a server (I think that's a given here).
     The student buys a BLANK OD from the Campus Store for REAL cheap.
     Say $10 (not too bad for 256 MB, we want them to buy it, remember?)
     Now SUPPOSE the hacker supreme figures out all the stuff he needs
     to get from the server, and, BTW, I hide all the juicy stuff like
     rc, rc.boot, hostconfig, etc. Now suppose he figures out the REAL
     root password to enable him to use netinfo over its security. Now
     suppose he (I use "he" here because he/she is tougher to type, no 
     implications necessarily infered or implied) suppose he can also 
     get to the proper gateway IPs and nameserver hosts (yep, you guessed
     it, I hide the full host-table elsewhere, users see a REAL limited
     local listing, and the gateway IPs are no where to be seen). Well
     fellow administrators, if they can do this, then, really, is there
     anything you can do without living in the facility and installing
     cameras everywhere. The kiddies will have 256 MB of portable data!
     That should take the average CS student through four years PLUS some!
     If they want to offload Apps, fine. If they want to caoy 'em to
     /u/<person>, fine...1.0 should (it better!) have quotas supported, they'll
     learn the hard way.
 
     The other concept is to say, to heck with it. No NET! You only really
     need it for printing, and the kids can walk a disk over if they need
     to (I think I spent too many years running PC/MAC facilities!). Now
     what about faculty/student mail. Well, folkes, that's why we have
     departmental mailboxes. I know, sounds like a return to the old days.
     Look, all I'm saying (the VERBOSE BIT is ON!!!) is that Steve RAISED
     the lowest common denominator a ton with portable 256 MB media. Most
     have praised this (me too!) some have problems with it. Security will
     ALWAYS be a #@$% pain if the machine is sitting in front of the user.
     The ROMs will help a little, but as someone mentioned already, 
     most University kids are fairly normal and well socialized. I have a 
     facility with 32 NeXTen (like Vaxen?...just a thought) all networked
     to our Engineering Quad Ethernet and I sleep well! And this campus
     spawned Morris!
 
Thanks for listening:

Roger Jagoda
FQOJ@CORNELLA
FQOJ@CORNELLA.CIT.CORNELL.EDU
 
RULES OF MEDICAL SCHOOL:
         
                         Air goes in and out...
                         Blood goes round and round...
                         Oxygen is good!