ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (11/22/88)
I saw one the other day. The use that silly new IBM/new DEC/ISO stupid keyboard format, with the ESC key in the wrong place. (I was told it can be remapped, but so what?) Is anyone thinking (or asked NeXT) about buying a totally diskless machine? It might be useful for public clusters of machines where you don't want to let the user control the state of the machine by booting up a special copy of the operating system (maybe this will only be a problem at CMU). The extant Mach installations around here (on Suns, for example) don't yet completely support diskless servering/booting, but there must be SOME way to do it. Probably boot prom mods at least are required. After all, if you can NFS it, you can keep the stuff normally on the optifloppy on a fast hard disk, and the ethernet interface should be capable of ~8Mbps peak (assuming Van Jacobsen's header-prediction TCP stuff will port) So it should be as good a diskless machine as a diskless Sun. And it gives the NeXT more of a 'product family' feel, since you can get a variety of disk types (none, magnetic, opto-magnetic) and (eventually) CPU types (1-4 processors). And, I can almost afford a $5K diskless machine, then buy whatever the best disk technology is before I leave the University. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)" --
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (11/23/88)
In article <3638@pt.cs.cmu.edu> ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) writes: >I saw one the other day. The use that silly new IBM/new DEC/ISO >stupid keyboard format, with the ESC key in the wrong place. (I was >told it can be remapped, but so what?) The one that I configured into our network last week (name, address, ifconfig, route, named, NFS, YP, voila) had a key at the upper-left corner imprinted with ` and ~ (like a Macintosh). It had already been remapped (like my Macintosh under uw) to ESC. >Is anyone thinking (or asked NeXT) about buying a totally diskless machine? They said that they can boot over NFS, but *every* machine will have the optical drive. >It might be useful for public clusters of machines where you don't want >to let the user control the state of the machine by booting up a special >copy of the operating system (maybe this will only be a problem at CMU). Heck no, large networked installations are everyone's problem :-) Hopefully there will be a way to ignore suid and sgid bits on filesystems mounted from the optical disk, at the very least. There are lots of other things to worry about. I'd want to completely disable booting from the floppy on a non-secure workstation. In a network environment, I'd want to completely disable booting from any local Winchester disk, as well. >The extant Mach installations around here (on Suns, for example) >don't yet completely support diskless servering/booting, but there >must be SOME way to do it. Probably boot prom mods at least are >required. Hmmm, we had heard that CMU was working on diskless Sun booting for their Mach. We're looking forward to using it here. I don't know whether CMU's scheme will be the same as NeXT's scheme, but that probably depends upon how much is being fed back from NeXT to CMU, and how closely NeXT is tracking CMU's work. Without NeXT's Mach sources, it would be pretty hard to choose one or the other. >...and the ethernet interface should be capable of ~8Mbps peak >(assuming Van Jacobsen's header-prediction TCP stuff will port) The Van TCP stuff is already there, I was told.
kean@mist.cs.orst.edu (Kean Stump) (11/23/88)
Would someone who has a NeXT check to see if the 0.8 release has the (ahem)
recent security patches to sendmail/ftpd/fingerd implemented ? (Or, you can
tell me the name/internet # of you machine and I'll check 8}}}})
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"
-------------------------------------------------------------------------------wrs@pupthy.PRINCETON.EDU (William R. Somsky) (11/23/88)
In article <3638@pt.cs.cmu.edu> ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) writes: >> I saw one the other day. They use that silly new IBM/new DEC/ISO >> stupid keyboard format, with the ESC key in the wrong place. >> (I was told it can be remapped, but so what?) In article <28185@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) replies: > The one that I configured into our network last week (name, address, > ifconfig, route, named, NFS, YP, voila) had a key at the upper-left > corner imprinted with ` and ~ (like a Macintosh). It had already been > remapped (like my Macintosh under uw) to ESC. Yeah, Ok, but where do you put the `/~ key then? This is no `:-)'. I need that key as well. Just as one example, I need the `~' and ``' for typing TeX source. Since keys like ESC and `/~ have been generally available up to now, they're used---and not necessarily infrequently either. Others may have different opinions, but I think it's a big mistake to take them away. Or move them about in wierd ways... Ever sit down at a VT220 keyboard and try to find the ESC? (I think it's a VT220... I don't like 'em, so I don't use 'em, and hence aren't familiar with 'em.) My editor of choice is 'vi' (no editor wars, please), and for that you need ESC FREQUENTLY. ------------------------------------------------------------------------ William R. Somsky Physics Dept ; Princeton Univ wrs@pupthy.Princeton.EDU PO Box 708 ; Princeton NJ 08544
pcg@aber-cs.UUCP (Piercarlo Grandi) (11/25/88)
In article <28185@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: Heck no, large networked installations are everyone's problem :-) Hopefully there will be a way to ignore suid and sgid bits on filesystems mounted from the optical disk, at the very least. There are lots of other things to worry about. I'd want to completely disable booting from the floppy on a non-secure workstation. In a network environment, I'd want to completely disable booting from any local Winchester disk, as well. The only thing I'd worry about is adopting this heavy handed, ineffectual approach to network security. Please refer to comp.protocols.tcp-ip (and comp.unix.wizards). It has been repeated to the point of exhaustion that security in a networked environment is obtained by suitable protocol emanating from trusted bases, not by network based physical restrictions (some innocent soul even admitted that she had never thought that someone could easily start filtering packets on an ethernet for passwords), and people have expended vast research efforts on these issues. Projects Andrew and Athena have done a lot of good work on network security where there are thousands of non trusted machines around, and there are no restrictions on their use. Go and learn about them. gentle reader, please type n if you do not like mild flames on the performance and instincts of many system administrators. *MILD FLAME ON* Many sys admins with a delusion of "management" have a gut instinct that the best way to achieve something is by inconveniencing users and imposing restrictions. Well, not only this is unnecessary, it is also quite ineffectual, because it is easily circumvented in most cases, and certainly in the one this article is about. I have seen enough of the: There ought to be a LAW against *users* being allowed to *boot*, hitherto an arcane ritual only allowed to the inner sanctum! We must protect our privileges, even at the cost of pretending that by forbidding *users* (the five letters word) to do certain things real security will be achieved. attitude to be fed up. As somebody pointed out, the first thing new *users* are told at MIT is the root password and yet security is probably better there than in a network in which users cannot use the suid/sgid facility, and cannot boot their own machines from whatever disk they want; this probably means that sys admins at MIT are not obsessed with their status and power that they think that it is the key to every problem. I really *despise* system administrators that think that since they are the boss all problems can be most effortlessly resolved by dictum from above and display of authority, when the only problems are the limits to their knowledge and imagination. By the way, I have been a sys admin myself, on and off since 1977, for fairly large systems and then networks, and I have always felt confident enough of my quality to know that I could usually find a solution to most problems that does not restrict users' choices and options if only I thought a bit harder about it. I have never felt like playing the master wizard game, I did not have the time to spare to pose. *MILD FLAME OFF* -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
pcg@aber-cs.UUCP (Piercarlo Grandi) (11/25/88)
In article <267@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: In article <28185@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: [ suggests that to secure machines on a net you restrict the ability of users to boot from local disks, etc...] [ I comment that this is a badly misguided approach to the problem, and add some flames on a cathegory of sysadmins that draw the gun whenever a problem threatens their "control" ] I would like to add a couple of points; bob@allosaur is obviously a knowledgeable UNIX user; I did not mean to include him in class of sysadmins targeted by my flames. It is my strong, strong impression that the NeXT is designed for the Andrew environment; NeXTs are meant to be slef service workstations, into which anybody can put their removable disk, upload (parts of) it to a fast server, work, adn then dump things back to the floppy. This explains both the absence of a fast disk, and the essential role of a removable backup, which if able to provide random access much better as personal repository, from/to which parts are copied to a remote server. A tape would have meant saving and restoring its contents in their entirety to a server. In this view it is obvious that workstations are NOT trusted at all; they may be used for whatever purpose, even os development; it is trusted servers and end-to-end links that must be protected by encryption and encryption based authentication. To suggest that the NeXT is the machine FOR students is ok, as long as this is meant as to provide service for the students, not for students to own. I can assure everybody that a 95 ms. disk makes a standalone UNIX machine unbearable (I did once run a 386 UNIX 5.3 on an AT clone with a 3.5" hard disk with that despicable access time, and even with nearly two megabytes of file system cache thins were pretty glib; thank goodness it was only temporary). Even a 40ms disk is not really enough. You must go down to 25-28ms to get quite respectable performance. -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
leein@uicsrd.csrd.uiuc.edu (11/26/88)
The ASCII code for ESC is actaully that for ^[ (Ctrl-[). So there is a way
to type the ESC key for any kind of keyboards, although it is not neat.
In gnuemacs, if you can remap alt-key for Meta, you do not use the ESC key
as heavily as in vi. What I think the NeXT keyboard is missing, or what
the NeXT people should think, is the
function keys. Don't say "What?". In technical word processer, we,
engineers or scientists (I am not CStist) need math keys, Greek keys, Script
keys, italic keys, and and bold keys. And the best places for
activating those keys are the function keys. If one can remap the numeric
keypad keys for those functions, then it's OK.
Hughseiffert@silver.bacs.indiana.edu (Kurt A. Seiffert) (11/28/88)
In article <37800001@uicsrd.csrd.uiuc.edu> leein@uicsrd.csrd.uiuc.edu writes: > > ... What I think the NeXT keyboard is missing, or what >the NeXT people should think, is the >function keys. Don't say "What?". In technical word processer, we, >engineers or scientists (I am not CStist) need math keys, Greek keys, Script >keys, italic keys, and bold keys. And the best places for >activating those keys are the function keys. > > > Hugh I haven't had any hands on experience with the NeXT yet, but judging from the demo I saw there is no need for function keys. NeXT seems to have adopted the Mac style of handling things like bold and italic. You merely type something like command-B for bold. Or you could select the items to be in bold and then the keystroke. (There are probably menu equivalents as well.) For Greek symbols and such an alt or option key can supply many of those. In the Mac things like the summation sign are right at your fingertips with something like option-E for sigma. If the particular symbols that you want are not available, switch to a different font, like Symbol font for the Mac. Fonts will map a different graphics representation on to a given code. So by switching fonts you can have letters that look like Old English or something out of Startrek or even ruins and symbols. Postscript Display means WYSIWYG (What You See Is What You Get). The need for function keys to get other types of commands is handled by the mouse. Kurt A. Seiffert Indiana University, Bloomington ---------------------------------------------------------------------- Cognitive Science at IU has arrived. ----------------------------------------------------------------------
romig@stegosaur.cis.ohio-state.edu (Steven M. Romig) (11/29/88)
In article <267@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <28185@tut.cis.ohio-state.edu> >bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > [Bob comments on problems with the local disk and the removable > optical disk.] >The only thing I'd worry about is adopting this heavy handed, >ineffectual approach to network security. Please refer to >comp.protocols.tcp-ip (and comp.unix.wizards). It has been repeated to >the point of exhaustion that security in a networked environment is >obtained by suitable protocol emanating from trusted bases, not by >network based physical restrictions (some innocent soul even admitted >that she had never thought that someone could easily start filtering >packets on an ethernet for passwords), and people have expended vast >research efforts on these issues. > >Projects Andrew and Athena have done a lot of good work on network >security where there are thousands of non trusted machines around, and >there are no restrictions on their use. Go and learn about them. Sigh. The Andrew and Athena projects are certainly valuable, but they don't solve all of the security problems that administrators are faced with. If folks have root access to a workstation, then they can install trojan horses on that workstation and get the passwords of unsuspecting users (or worse). Or they can change their network configuration information and cause no small amount of confusion for the administrative staff. Etc. And aside from that, the NeXT workstation is not using the Athena software or the Andrew software (yet). >Many sys admins with a delusion of "management" have a gut instinct >that the best way to achieve something is by inconveniencing >users and imposing restrictions. Well, not only this is unnecessary, it >is also quite ineffectual, because it is easily circumvented in most >cases, and certainly in the one this article is about. Agreed. However, one of the main roles of a system administrator in a distributed computing environment is to provide certain services and facilities to the users with a certain measure of guarantee that they aren't going to get screwed by something or someone, including other users. The Athena project solves a large part of the problem in that they provide a way to authenticate users and services and machines on the network. They don't solve all of the problems, however. For instance, version control. A user may have a disk with version X of the NeXT software with has some serious bug that we have fixed on all of our N hundred NeXT workstations. The bug causes lots of network traffic to be generated, which effectively brings one or more servers to their knees for one reason or another. As a sys admin, I want to not only fix that user's disk, but I would prefer that when people connect a NeXT machine to that network, that they use the current, up to date configuration which fixes all of the known problems. It is unreasonable to assume that every user will be responsive enough to update their own disks (we have 300 Macs, we know what happens when you try to get everyone to change the printer driver software on ther disks). And it is responsible and correct (I think) for the sys admin to impose some sort of restrictions on how the workstations are used. In this case, setting up the NeXt workstations so that they boot from the local disk or from a network boot server would be my choice of solution - I would still want users to be able to mount their optical disk and all that, its just that if they are going to use my network, they are going to play my networks game by my networks rules. I agree that those rules should not be too restrictive, but they are there, and they are part of being a responsible system administrator. >-- >Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk >Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg >UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK) --- Steve Romig romig@cis.ohio-state.edu CIS Department, The Ohio State University
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (11/29/88)
In article <267@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <28185@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >>Hopefully there will be a way to ignore suid and sgid bits on >>filesystems mounted from the optical disk, at the very least. There >>are lots of other things to worry about. Note those last two phrases. That one detail is only part of a plan that can be implemented using capabilities that are available to us right now. See below... >...security in a networked environment is obtained by suitable >protocol emanating from trusted bases, not by network based physical >restrictions..., Agreed. >...and people have expended vast research efforts on these issues. And they're approaching some potential strategies toward a workable solution. >Projects Andrew and Athena have done a lot of good work on network >security where there are thousands of non trusted machines around, >and there are no restrictions on their use. Go and learn about them. We've looked into the work done at CMU and MIT. The stuff that Athena has produced looks promising, and we expect to adopt some of it. However, (1) As Steve pointed out, it doesn't solve all the problems yet. (2) It's not all generally available yet. (3) Not everything is hooked into it yet (e.g. X, NeWS, NeXT Step). (4) The most interesting and useful parts require source modifications to the software supplied by the various vendors. We have had immense problems getting sources for everything in our stable, and so far only HP and Encore have come through with even part of their stuff. Nothing yet from Sun or Pyramid or BBN, though at least our Sun source tapes are "in the mail". NeXT sources may be awfully hard to come by. Faced with the lack of ability to make the vendors' software more useful in our own environment (because they won't let us), we are forced to resort for now to more distasteful, "heavy handed" strategies. I'm looking forward to GNU. Even if RMS doesn't like security measures, we'll have full sources so we will be able to add whatever we want to.
cmf@cisunx.UUCP (Carl M. Fongheiser) (11/29/88)
In article <28493@tut.cis.ohio-state.edu> romig@stegosaur.cis.ohio-state.edu (Steven M. Romig) writes: >If folks have root access to a workstation, then they can >install trojan horses on that workstation and get the passwords of >unsuspecting users (or worse). Gee, Steve, give me ten minutes with a non-root account on one of your workstations, and I virtually guarantee that I can get the password for the next person who walks up to it. Why do you need root access to get people's passwords? It hardly even makes it easier! Carl Fongheiser University of Pittsburgh ...!pitt!cisunx!cmf cmf@unix.cis.pittsburgh.edu
sbb@esquire.UUCP (Stephen B. Baumgarten) (11/30/88)
In article <37800001@uicsrd.csrd.uiuc.edu> leein@uicsrd.csrd.uiuc.edu writes: >What I think the NeXT keyboard is missing, or what >the NeXT people should think, is the >function keys. Steve still doesn't believe in them. Actually, I'm surprised the NeXT machine has a fan (it *does* have a fan, right?). -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
romig@stegosaur.cis.ohio-state.edu (Steven M. Romig) (11/30/88)
cmf@cisunx.UUCP (Carl M. Fongheiser) writes: > Why do you need root access to get people's passwords? It hardly even > makes it easier! Good point. I wasn't very clear about what I meant in my note. I don't care so much about the passwords themselves - I'm more concerned about the system software. There are two cases - either you have a local disk of some sort, or you boot diskless (with the possibility that you may boot remotely, but swap to a local disk). In the case of a local disk of some sort, I expect that someone can and possibly will become root and muck about with the system software. Random users cannot detect (and thereby fix) that, and may get screwed by it (ala Trojan horses and so on). As a system administrator, I can't prevent this, since they wouldn't have to deal with a Kerberos authentication server on the net to do their damage. Basically, by booting from a local disk, I put the system software into the users hands. A user has no "guarantee" that he can boot this workstation and use the "correct" system software. In the case of a diskless workstation, I've got to deal with network services to boot and mount file systems and all that - I have a flying chance of maintaining some semblance of security using something like Kerberos. Someone may still choose to bring an optical disk and boot off of that, but they can probably be prevented from futzing with the system software across the network. That means that the next user to come along can boot the workstation and can be "guaranteed" to have a correct copy of the system to work with. Neither of these says anything about someone taking advantage of security holes to become root and futz with the system software, of course. That's a different problem. The point isn't that people can spoof other folks out of their passwords - of course they can, even without root access. The point I was making is that using local disks puts the software in the hands of the user. Some people may choose to do that - I would rather not, but I won't have any choice about it if NeXT doesn't support diskless workstations. --- Steve Romig romig@cis.ohio-state.edu CIS Dept., The Ohio State University
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (11/30/88)
In article <28659@tut.cis.ohio-state.edu> romig@stegosaur.cis.ohio-state.edu (Steven M. Romig) writes: >The point I was making is that using local disks puts the software in >the hands of the user. ...which is fine and dandy in some installations, but we're leery about it here where most people are only very transiently associated with a particular workstation. Some companies give individual users complete responsibility for, and control over, the box beside his/her desk. If he hurts anyone, it's only himself. Here, only the lucky few (like me :-) with machines in their offices might use a particular one more often than anyone else in the department would. And even those hosts are available to the unwashed masses for dial-in access. But the great majority of our workstations are out in semi-public labs, where anyone off the street has direct physical access, and any CIS undergrad above the 200 level courses has an account. Those people expect Steve and me to keep each one acting just like the one next to it. >Some people may choose to do that - I would rather not, but I won't >have any choice about it if NeXT doesn't support diskless >workstations. We could always keep buying Suns, and not let NeXT make our choices for us.
ugbernie@sunybcs.uucp (Bernard Bediako) (12/01/88)
In article <28659@tut.cis.ohio-state.edu> romig@stegosaur.cis.ohio-state.edu (Steven M. Romig) writes: >cmf@cisunx.UUCP (Carl M. Fongheiser) writes: >> Why do you need root access to get people's passwords? It hardly even >> makes it easier! [ stuff deleted] >There are two cases - either you have a local disk of some sort, or >you boot diskless (with the possibility that you may boot remotely, >but swap to a local disk). In the case of a local disk of some sort, I don't really understand this point. I thought that each user would have his OWN optical disk; meaning it did contain an /etc/passwd. The disk wouldn't contain anyone else's acct. infomation. It should work close to the same way as a 'partially diskless workstation' where the user loads up with his disks, but runs mosts of the desired commands (commands that shouldn't be controlled by the user, btu kept in the traditonal way on the main disk server) off the remote computer/drive. This way some the commands on his disk are either the equivalents of a /usr/local/bin or the users personal bin. I'm not really certain what kinds of progs. should be kept on the user's disks though. Maybe things like the editor, or progams in general that could be used normally on a single user system (basically enough to advantadge of that extra space) I'm sure most people using them wont need 100+ Megs for their own personal disk space (but maybe :-) >In the case of a diskless workstation, I've got to deal with network >services to boot and mount file systems and all that - I have a flying >chance of maintaining some semblance of security using something like >Kerberos. Someone may still choose to bring an optical disk and boot >off of that, but they can probably be prevented from futzing with the >system software across the network. That means that the next user to >come along can boot the workstation and can be "guaranteed" to have a >correct copy of the system to work with. [stuff deleted] >The point isn't that people can spoof other folks out of their >passwords - of course they can, even without root access. The point I >was making is that using local disks puts the software in the hands of >the user. Some people may choose to do that - I would rather not, but >I won't have any choice about it if NeXT doesn't support diskless >workstations. > If the person loads up with his disk, and has to log onto the remote server/drive, security could be kept up to the point of having the remote machine not give root (or anything similar) to the user;to that machine I would just be a user with access to whatever root of that machine determines I can have. And keeping people off the remote is as simple as locking it somewhere safe! >--- Steve Romig romig@cis.ohio-state.edu > CIS Dept., The Ohio State University bernie ------------------------------------------------------------------------ Bernard Bediako SUNY/Buffalo Computer Science UUCP: ..!{ames,boulder,decvax,rutgers}!sunybcs!ugbernie Internet: ugbernie@cs.Buffalo.EDU BITNET: ugbernie@sunybcs.BITNET ------------------------------------------------------------------------ Bernard Bediako SUNY/Buffalo Computer Science UUCP: ..!{ames,boulder,decvax,rutgers}!sunybcs!ugbernie Internet: ugbernie@cs.Buffalo.EDU BITNET: ugbernie@sunybcs.BITNET
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (12/02/88)
In article <2993@cs.Buffalo.EDU> ugbernie@sunybcs.UUCP (Bernard Bediako) writes: >I don't really understand this point. I thought that each user would have >his OWN optical disk; meaning it did contain an /etc/passwd. >The disk wouldn't contain anyone else's acct. infomation. Someone said they had seen the NeXT boot diskless. If this is so, one could mount root, /usr, /etc etc. from a server, and mount the mopty as something like /untrusted (or something less value laden). One could then prevent corruption entirely on the server by not permitting remote root [individual users] to alter server-provided file systems. They could, in fact, be advertised read-only, leaving swap and /joe on the user's mopty. I think this would address the security problems for file systems. Other concerns, of course, still need good solutions. Jon