asg@sage.cc.purdue.edu (The Grand Master) (05/08/91)
In article <1991May7.224644.16951@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: }In article <12021@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: }|> Are you telling me that when you log in, you have to wait for your home }|> directory to be mounted on the workstation you log in on? } Yes. }|> - This is }|> absolutely Horid!! } I would suggest, Bruce, that you refrain from commenting about things about }which you know very little. Your entire posting is filled with jibes about }the way Project Athena does things, when you appear to know very little about }*how* we do things or about the history of Project Athena. Well I am glad you are expanding my knowledge } I doubt that DEC and IBM would have given Athena millions of dollars over }more than seven years if they thought it was a "kludge". I doubt that }Universities and companies all over the world would be adopting portions of }the Project Athena environment if they thought it was a "kludge". I doubt DEC }would be selling a bundled "Project Athena workstation" product if they }thought it was a "kludge". I doubt the OSF would have accepted major portions }of the Project Athena environment in their DCE if they thought it was a }"kludge". The old Iidea that "it is a good idea if people put money into it" Remember the HUNDREDS OF MILLIONS SPENT ON PET ROCKS?? THe fact that money has been put into the project is not indicative of Project Athena's worthefullness. Ford put alot of money into the Edsel. } You have the right to express your opinion about Project Athena. However, }when you opinion is based on almost zero actual knowledge, you just end up }making yourself look like a fool. Before allowing that to happen any more, I The good old JIK tactic - when someone disagrees with you, tell them they look like a fool. }suggest you try to find out more about Athena. There have been several I am attempting to do just that so that I have an example of how *NOT* to administrate a network. } You also seem to be quite in the dark about the future of distributed }computing. The computer industry has recognized for years that personal }workstations in distributed environments are becoming more popular. I have }more computing power under my desk right now than an entire machine room could }hold ten years ago. With the entire computing industry moving towards }distributed environments, you assert that Project Athena, the first successful }large-scale distributed DCE in the world, would be better off "to have a few }powerful centralized systems with Xwindow terminals instead of separate }workstations." Whatever you say, Bruce; perhaps you should try to convince }DEC, IBM, Sun, HP, etc. to stop selling workstations, since the people buying }them would obviously be better off with a few powerful centralized systems. You do not however have any more power (in fact quite a bit less) than systems which now occupy about the same volume as my desk. } }|> Next, at the top level of each filesystem you but a directory named }|> tomb - in other words, instead of the jik directory being the only }|> directory on your partition, there are two - jik and tomb. } } "Filesystems" are arbitrary in our environment. I can mount any AFS }directory as a "filesystem" (although AFS mounts are achieved using symbolic }links, the filesystem abstraction is how we keep NFS and AFS filesystems }parallel to each other). Furthermore, I can mount any *subdirectory* of any }NFS filesystem as a filesystem on a workstation, and the workstation has no }way of knowing whether that directory really is the top of a filesystem on the }remote host, or of getting to the "tomb" directory you propose. You dinna read then. Since the filesystem(s) in question would be remote filesystems, and rpc protocal would be sent TO THE SYSTEM THAT ACTUALLY HAS THE DIRECTORY MOUNTED ON IT!!! Therefore there is no problem in finding the root of the filesystem. } } If your site uses "a few powerful centralized systems" and does not allow }mounting as we do, then your site can use the entomb stuff. But it just }doesn't cut it in a large-scale distributed environment, which is the point }I've tried to make in my previous two postings (and in this one). You can have a large scale distributed environment without allowing people to mount their own directories. We have such at Purdue with the few centralized systems (yes, you can all sing along) with Xwindows terminals. We also have it here at GE where each person who has a workstation can still log into anny workstation and be able to access his disk without having to do mounting all over the place. If I want to get to a directory /tmp on the system a294 I do cd //a294/tmp - no problem. } } In any case, mounting user home directories on login takes almost no time at }all; I just mounted a random user directory via NFS and it took 4.2 seconds. }That 4.2 seconds is well worth it, considering that they can access their home 4.2 seconds is too long in my book when it can be done without having to wait to mount your home directory. }directory on any of over 1000 workstations, any of which is probably as }powerful as one of your "powerful centralized systems." Where you get this I have no idea. I want to see your workstations if they are as powerful as a Sequent Symmetry. Pretty damn good workstations I guess. } }|> What these functtions will actually do is }|> call on a process entombd (which runs suid to root - ohmigod) to move }|> your files to the tomb directory. } } One more time -- setuid does not work with authenticated filesystems, even }when moving files on the same filesystem. Your solution will not work in our }environment. I do not know how many times I am going to have to repeat it }before you understand it. So automated tasks are impossible (or at least more difficult) on your authenticated filesystem - I am begining to see the merits in Athena. ( ;-) added for the humor impaired ) } }|> If the file to be entombed is NFS mounted from a remote }|> host, the entomb program would be unable to move it to the }|> tomb because of the mapping of root (UID 0) to nobody (UID }|> -2). Instead, it uses the RPC mechanism to call the entombd }|> server on the remote host, which does the work of entombing. } } We considered this too, and it was rejected because of the complexity }argument I mentioned in my last posting. Your daemon has to be able to figure }out what filesystem to call via RPC, using gross stuff to figure out mount }points. Even if you get it to work for NFS, you've got to be able to do the }same thing for AFS, or for RVD, which is the other file protocol we use. And }when you add new file protocols, your daemon has to be able to understand them }to know who to do the remote RPC too. Not generalized. Not scalable. It is ALREADY WORKING! } } Furthermore, you have to come up with a protocol for the RPC requests. Not }difficult, but not easy either. The protocol has been defined since it is already working. } } Furthermore, the local entombd has to have some way of authenticating to the }remote entombd. In an environment where root is secure and entombd can just }use a reserved port to transmit the requests, this isn't a problem. But in an }environment such as Athena's where anyone can hook up a PC or Mac or }workstation to the network and pretend to be root, or even log in as root on }one of our workstations (or public workstation root password is "mroot"; [Give me the addresses (or do I have to log in from the console?)] }enjoy it), that kind of authentication is useless. Oh, I like your setup even better now. Give all the users root! Very tidy, and secure. You were complaining aboutquota's earlier and you give you users all root privs????????? I know. That is the reason for the elaborate autentication system - but tell me, if you dinna let your users have root privs would you NEED the elaborate authentication system? } } No, I'm not going to debate with you why people have root access on our }workstations. I've done that flame once, in alt.security shortly after it was }created. I'd be glad to send via E-mail to anyone who asks, every posting I }made during that discussion. But I will not debate it again here; in any }case, it is tangential to the subject currently being discussed. yes - email them to me } } By the way, the more I read about your entomb system, the more I think that }it is a clever solution to the problem it was designed to solve. It has lots }of nice features, too. But it is not appropriate for our environment. And giving away root privs is. What is the purpose of having semarate accounts then? Or do you have to give some kind of Kerberos authentication code for every damn thing you do? } }|> } Um, the whole idea of Unix is that the user knows what's in the file }|> }hierarchy. *All* Unix file utilities expect the user to remember where files }|> }|> Not exactly true. Note this is the reason for the PATH variable, so that }|> you do not have to remember where every God-blessed command resides. } } Running commands is different from manipulating files. There are very few }programs which manipulate files that allow the user to specify a filename and }know where to find it automatically. And those programs that do have this }functionality do so by either (a) always looking in the same place, or (b) }looking in a limited path of places (TEXINPUTS comes to mind). I don't know }of any Unix program which, by default, takes the filename specified by the }user and searches the entire filesystem looking for it. And no, find doesn't I did not propose looking through the whole filesystem, just looking through a certain number of specific places (the tomb directories). In fact, you only have to look in one at a time (the tomb dir on your filesystem). } }|> Well, then this is an absolute kludge. How ridiculous to have to mount and }|> unmount everyones directory when they log in/out. ABSURD!. } } See above. What you are calling "ABSURD" is pretty much accepted as the }wave of the future by almost every major workstation manufacturer and OS }developer in the world. Even the Mac supports remote filesystem access at }this point. I never said remote filesystem access was a kludge. Having to wait for your home directory, and users being allowed to moun other directories at will, and users being given the root pasword, and then creating an authentication system to close up the wholes made by giving users access to root privs - now *THAT* is a kludge. } } How else do you propose a network of 1000 workstations deal with all the }users' home directories? Oh, I forgot, you don't think anyone should need to }have a network of 1000 workstations. Right, Bruce. I think that there are other viable solutions. But as I said, it is still possible to handle users directories on a net of 1000 workstations without your ridiculous kludge. As GE has done. } }|> In fact, what you have appearantly makes it impossible for me to access }|> any other users files that he might have purposefully left accessable }|> unless he is logged into the same workstation. } } No, we have not. As I said above, you don't know what you're talking about, }and making accusations at Project Athena when you haven't even bothered to try }to find out if there is any truth behind the accusations is unwise at best, }and foolish at worst. Project Athena provides "attach", an interface to }mount(2) which allows users to mount any filesystem they want, anywhere they }want (at least, anywhere that is not disallowed by the configuration file for }"attach"). All someone else has to do to get to my home directory is type }"attach jik". first - I said appearantly, which denotes some measure of uncertainty. Second - Well, I just don't think it is wise to allow others to mount filesystems when and where they want at will. } } Do not assume that Project Athena is like Purdue and then assume what we don }on that basis. Project Athena is unlike almost any other environment in the }world (although there are a few that parallel it, such as CMU's Andrew system). } I never assumed Athena was anything like Purdue. Purdue's environment is set up sanely. }|> And if I am working on a workstation and 10 people happen to rlogin }|> to it at the same time, boy are my processes gonna keep smokin. } } Workstations on Project Athena are private. One person, one machine (there }are exceptions, but they are just that, exceptions). } Oh, you do not support rlogin - ic. So tell me, how do I get at my files from a remote location? }|> No the idea of an Xterminal with a small processor to handle the }|> Xwindows, and a large system to handle the rest is MUCH MUCH more reasonable }|> and functional. } } You don't know what you're talking about. Project Athena *used to be* }composed of several large systems connected to many terminals. Users could }only log in on the cluster nearest the machine they had an account on, and }near the end of the term, every machine on campus was unuseable because the }loads were so high. Now, we can end up with 1000 people logged in at a time }on workstations all over campus, and the performance is still significantly }better than it was before we switched to workstations. Maybe that is also because computer technology has improved. How many computers did you have in your "cluster"? What kind of processors did they have. Our Sequent's (sage is one of them) often have 200 users working fervently to finish a CS project, withe very little appreciable slow-dowm. And this is just with 8 of the 40 processors that a Sequent can hold. When I say powerful central computers, I *MEAN* *POWERFUL* . I do not mean one centralized workstation, or even a VAX. Don't tell me that a cluster of 25 or more sequents won't do the same job that 1000 workstations can do. } }|> It is my perogative to announce my opinion on whatever the hell I choose, }|> and it is not yours to tell me I cannot. Again this seems like a worthless }|> stupid kludge. What is next - a password so that you can execute ls? } } You asserted that we should not be writing to system source code with our }own account. I responded by pointing out that, in effect, we are not. We }simply require separate Kerberos authentication, rather than a completely }separate login, to get source write access. Now you respond by saying that }that authentication is wrong, when it is in fact what you implied we should be }doing in the first place. } I feel the authentication is unneccesarily neccesary. You have made it a neccesity by putting power in the users' hands that should not be there. I will not applaud you for making things more difficult. Why should I have to use a password every time I execute a command? (I know, you don't have to for *EVERY* command - yet). What is the purpose of separate accounts? It is so that you have to enter a password only once. If not, you could just have open connected terminals and require a password for any special commands (ls, vi, rm, kill). No need for accounts. }-- }Jonathan Kamens USnail: }MIT Project Athena 11 Ashford Terrace }jik@Athena.MIT.EDU Allston, MA 02134 }Office: 617-253-8085 Home: 617-782-0710 Just get a room full of Sequent Symmetry's. You will have more computing power than you know what to do with. --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
afoiani@nmsu.edu (Anthony "Tkil" Foiani) (05/09/91)
Just to add a bit of ammo to the current flame war. Since we seem to be in an argument of Compute Servers + X Window Terminals vs. File Servers + Workstations, and at the moment Purdue vs. Project Athena, I thought I'd comment via the following quote from the man page for X(1) "The X Window System is a network transparent window system developed at MIT..." And from _Bridging The X Information Gap_, a UNIXToday! supplement from March 1991: "In May 1984 Athena got its first stable VS100s, and throught that summer Scheifler did the initial work on the X protocol..." (p. 3) Makes me wonder. Cheers, Tony -- Tony Foiani a.k.a. Tkil (afoiani@nmsu.edu) or (mcsajf@nmsuvm1.bitnet) Supporting: Unix / DOS / VMS / Macintosh / "What's this?" "As the water flows over the bridge, | As we walk on the Floodland | "Rain From Heaven" As we walk on the water, we forget | _Gift_ We forget. Rain from Heaven." | The Sisterhood
jik@athena.mit.edu (Jonathan I. Kamens) (05/09/91)
In article <12049@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> The old Iidea that "it is a good idea if people put money into it" Remember |> the HUNDREDS OF MILLIONS SPENT ON PET ROCKS?? THe fact that money has been |> put into the project is not indicative of Project Athena's worthefullness. |> Ford put alot of money into the Edsel. The *facts* are: people are willing to invest in distributed computing research; the computing industry has been devoting huge amounts of resources to developing distributed computing; the computer industry's journals (such as the CACM and others) have discussed at length, many times, the advantages (and disadvantages) and recent developments in distributed computing; and there seems to be almost unanimous agreement both in academic and industry circles that distributed computing is worth pursuing as at least on alternative in the long list of ways to compute. In the face of this, you come along and assert that distributed computing is a bad idea. You are entitled to your opinion, Bruce. However, asserting that something is fact does not make it so. If you want to convince people that distributed computing is a bad idea, you're going to have to do more than assert it, and so far, that's all you've done. |> }one of our workstations (or public workstation root password is "mroot"; |> [Give me the addresses (or do I have to log in from the console?)] Public workstations, with the public root password, do not allow remote access. Machines that do allow remote access have a different root password. |> Oh, I like your setup even better now. Give all the users root! Very |> tidy, and secure. Root access on a public workstation grants no special powers in our environment. As I said, I will not debate that here. |> You were complaining aboutquota's earlier and you |> give you users all root privs????????? We give all users root privileges on public workstations. That does not give them any access they should not have to our services. As I said, I will not debate that here. |> I know. That is the reason for the |> elaborate autentication system - but tell me, if you dinna let your |> users have root privs would you NEED the elaborate authentication |> system? Yes, because it is impossible to insure that every machine on a network is secure. We have a huge wide-area campus area network, with machines on it that are run by many different organizations, departments, etc. We have Macs and PCs on the network that don't even have any *concept* of root privileges. When you cannot assume that root is secure on all machines on a network, then you must assume that it is *not* secure, and that is why the decision not to hide the public workstation root password was made. One more time: I discussed all this in alt.security. I will not debate it again here. |> And giving away root privs is. What is the purpose of having semarate |> accounts then? Or do you have to give some kind of Kerberos authentication code |> for every damn thing you do? Once again, "If you don't know how Project Athena works, don't slam it." Kerberos authentication is, for the most part, completely transparent to the user. To a Project Athena user, logging into one of our workstations is no different from someone logging in at Purdue. It was designed with that goal in mind. If you don't understand how this can be so, I suggest you learn more about Project Athena, or be quiet. |> } Running commands is different from manipulating files. There are very few |> }programs which manipulate files that allow the user to specify a filename and |> }know where to find it automatically. And those programs that do have this |> }functionality do so by either (a) always looking in the same place, or (b) |> }looking in a limited path of places (TEXINPUTS comes to mind). I don't know |> }of any Unix program which, by default, takes the filename specified by the |> }user and searches the entire filesystem looking for it. And no, find doesn't |> |> I did not propose looking through the whole filesystem, just looking |> through a certain number of specific places (the tomb directories). In fact, |> you only have to look in one at a time (the tomb dir on your filesystem). You're mixing apple with oranges. I asserted that it was a flaw not to remember when archiving deleted files where they were in the original filesystem. You responded by asserting that it is a flaw that a user has to remember where files were originally when undeleting them. I responded that *every* Unix utility requires users to remembers where files are. Now you're talking about remembering where the files are entombed, which is a completely different issue. |> and users being allowed to moun other directories |> at will, Users being allowed to mount other directories at will is a logical extension to the ability to mount remote filesystems. Placing unnecessary restrictions on the user is antithetical to the original design goals of Unix, and furthermore, it's counterproductive. If it is technically feasible to allow arbitrary filesystems to be mounted by the user, I fail to see how you can call it a kludge. Incidentally, both DEC and Sun both ship a version of mount that allows non-root users to do NFS mounts. I guess they don't think it's a kludge either. Oh, I know what you're going to say, "The fact that other people are doing it doesn't mean it's right." Fine, but the fact that other people are doing it provides a proponderance of evidence that it *may* be right, and you can't disprove that just by asserting otherwise. |> and users being given the root pasword, and then creating an |> authentication system to close up the wholes made by giving users access |> to root privs - now *THAT* is a kludge. The authentication system is designed to fix the fact that networks are not secure, and that you can never assume that every machine on your network is secure. Especially not on the Internet, when we *know* that this is not the case. This was discussed at length in alt.security. |> I think that there are other viable solutions. But as I said, it is |> still possible to handle users directories on a net of 1000 workstations |> without your ridiculous kludge. As GE has done. GE does it by cross-mounting all filesystems via NFS on all machines, right? Is it really true that you have 1000 machines, with all filesystems mounted on all of them? I find that somewhat hard to believe. In any case, you're right, it is possible to do it without explicit mounting. That's why we're working more and more with the Andrew File System (AFS) here at Athena. However, there are still advantages to being able to mount filesystems arbitrarily, since many people are going to be using NFS for a long time into the future, even if we start using AFS internally. |> first - I said appearantly, which denotes some measure of uncertainty. |> Second - Well, I just don't think it is wise to allow others to mount |> filesystems when and where they want at will. The industry appears to disagree with you. And you have yet to provide any justification for not thinking it is wise. |> } Workstations on Project Athena are private. One person, one machine (there |> }are exceptions, but they are just that, exceptions). |> Oh, you do not support rlogin - ic. |> So tell me, how do I get at my files from a remote location? You log into the dialup hosts. Which are not "public workstations," and which do not have a public root password. |> I feel the authentication is unneccesarily neccesary. You have made |> it a neccesity by putting power in the users' hands that should not |> be there. I will not applaud you for making things more difficult. Um, how is it more difficult for me to have to type two commands in my current environment to get write access to the source tree (if I am allowed that access), while allowing to keep my entire environment, than it would be for me to have to log into a separate source maintenance account in order to modify the sources? And let's not forget that under the Athena system, there is accountability, because the changes made to the source tree are made by the user ID of the user who made them, not by a special source maintenance account. To achieve that your way, you've got to have a separate source maintenance account for every person who's allowed to modify the source tree. |> Why should I have to use a password every time I execute a command? You don't have to do anything of the sort. And I don't see how you ever got the idea that you did. Authenticating to a restricted filesystem is a one-step operation, and the authentication stays until you revoke it (or until it expires), just as logging into a special account stays until you log out. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
henry@ADS.COM (Henry Mensch) (05/09/91)
background: i'm a former staff member of MIT's Project Athena and of the Purdue University Computing Center, and am familiar with the styles of computing available in both places. i represent only my personal opinion with this message, and do not represent the opinion of Project Athena or the Institute. asg@sage.cc.purdue.edu (The Grand Master) wrote: ->jik@athena.mit.edu (Jonathan I. Kamens) writes: ->asg@sage.cc.purdue.edu (The Grand Master) writes: ->}|> Are you telling me that when you log in, you have to wait for your home ->}|> directory to be mounted on the workstation you log in on? ->} Yes. ->}|> - This is ->}|> absolutely Horid!! everyone out there who uses sun's automounter is doing exactly the same thing (they are, of course, limited to the one networked file system that is supported by the automounter). it works quite well. i suggest you try it. ->The old Iidea that "it is a good idea if people put money into it" Remember ->the HUNDREDS OF MILLIONS SPENT ON PET ROCKS?? THe fact that money has been ->put into the project is not indicative of Project Athena's worthefullness. ->Ford put alot of money into the Edsel. you seem to have missed the major point of that last paragraph, which was the issue of industry acceptance of the athena model of distributed computing. the difference between the analogy you present and the reality of project athena is that the edsel did not survive, while the project athena network services are setting the standard and practice for distributed computing now and for some years to come. ->You do not however have any more power (in fact quite a bit less) than systems ->which now occupy about the same volume as my desk. consider this measure: divide the number of MIPS that your timesharing processor provides by the number of users sharing that processor. apply the same measure to the workstation user (remember that only one user uses a workstation at any one time). now please reconsider your statement. ->You can have a large scale distributed environment without allowing ->people to mount their own directories. We have such at Purdue with the ->few centralized systems (yes, you can all sing along) with Xwindows ->terminals. this is not a distributed computing environment. replacing character terminals with x terminals (did you know that the x window system came from project athena and is an athena network service?) does not make a distributed computing environment. ->We also have it here at GE where each person who has a workstation ->can still log into anny workstation and be able to access his disk without ->having to do mounting all over the place. If I want to get to a directory ->/tmp on the system a294 I do cd //a294/tmp - no problem. and how do you think //a294/tmp gets there? magic? maybe the workstation *gasp* mounts a filesystem there for your use when you make such a request. maybe they're using an automounter? ->It is ALREADY WORKING! nobody said it wasn't working. you didn't address jik's point that this solution did not scale to hundreds of servers and thousands of hosts. i do believe you only have a handful of sequents at purdue ... ->Oh, I like your setup even better now. Give all the users root! you obviously don't understand that (with single user hosts) any user can become root with little/no effort. project athena's architecture gets over this by making root (on a workstation) a commodity of limited value. our users don't get root privileges on servers (where data are kept and network services originate from). ->... but tell me, if you dinna let your ->users have root privs would you NEED the elaborate authentication ->system? see above. you already use an authentication system; it's just fairly weak and easy to exploit. ->Oh, you do not support rlogin - ic. ->So tell me, how do I get at my files from a remote location? you use a dialup server ... an exception (as jik described). the name "dialup server" is a misnomer--their most common usage is for users to dial into with real modems and phone lines, but they are easily accessible over the internet. bruce, you might do well to have a chat with the manager of UNIX systems at the computing center ... i know he has some clues about athena-style computing that you seem to be missing, and perhaps he can impart those to you in a way that you'll understand. i know he knows that not all of the athena solutions are useful for a place like PUCC, but i also know that there's some understanding that you don't seem to have ... -- # Henry Mensch / Advanced Decision Systems / <henry@ads.com>
asg@sage.cc.purdue.edu (The Grand Master) (05/09/91)
In article <1991May8.174603.26309@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: }In article <12049@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: } The *facts* are: people are willing to invest in distributed computing }research; the computing industry has been devoting huge amounts of resources } In the face of this, you come along and assert that distributed computing is }a bad idea. } Show me where I said this! What I have said is that your way of doing distributed computing is bad. } } Root access on a public workstation grants no special powers in our }environment. As I said, I will not debate that here. no of course you won't } } We give all users root privileges on public workstations. That does not }give them any access they should not have to our services. As I said, I will }not debate that here. Sorry, I just don't understand how giving anyone the right to mount any filesystem they wish, and then giving them root access to boot does not at all compromise system security. Maybe you can explain this. } }|> I know. That is the reason for the }|> elaborate autentication system - but tell me, if you dinna let your }|> users have root privs would you NEED the elaborate authentication }|> system? } } Yes, because it is impossible to insure that every machine on a network is }secure. We have a huge wide-area campus area network, with machines on it }that are run by many different organizations, departments, etc. We have Macs }and PCs on the network that don't even have any *concept* of root privileges. }When you cannot assume that root is secure on all machines on a network, then }you must assume that it is *not* secure, and that is why the decision not to }hide the public workstation root password was made. } Now it depends how you hook the Macs and PCs up to the network. And also, dunno about your PC's, put the Public PC's at Purdue DO have accounts for special functions, and you are not allowed to mess with certain things without the right authority (kind of a root-type idea) Now, if you are saying that the people in the computer dept do not know if they can trust the SYSADMINs in the MATH dept, well then you should do something about that. A workstation can be made such that you cannot boot it from floppy without a passwd (in fact my PC even does this), so physical access is not really an excuse. } One more time: I discussed all this in alt.security. I will not debate it }again here. No, of course you won't } } Once again, "If you don't know how Project Athena works, don't slam it." } } Kerberos authentication is, for the most part, completely transparent to the }user. To a Project Athena user, logging into one of our workstations is no }different from someone logging in at Purdue. It was designed with that goal }in mind. } } If you don't understand how this can be so, I suggest you learn more about }Project Athena, or be quiet. Then why don't you tell us oh master of computing? } }|> and users being allowed to moun other directories }|> at will, } } Users being allowed to mount other directories at will is a logical }extension to the ability to mount remote filesystems. Placing unnecessary UH - no }restrictions on the user is antithetical to the original design goals of Unix, }and furthermore, it's counterproductive. If it is technically feasible to }allow arbitrary filesystems to be mounted by the user, I fail to see how you }can call it a kludge. } It is not an unnecessary restriction. Again, Why don't you tell us how it can be that I can be allowed to mount any filesystem I choose, log in as root, and still not do harm to the any of your systems. At the very least, can I not wipe the entire root directory of the workstation clean? } }|> and users being given the root pasword, and then creating an }|> authentication system to close up the wholes made by giving users access }|> to root privs - now *THAT* is a kludge. } } The authentication system is designed to fix the fact that networks are not }secure, and that you can never assume that every machine on your network is }secure. Especially not on the Internet, when we *know* that this is not the }case. This was discussed at length in alt.security. Of course you cannot assume that every machine on the network is secure. you can however assume that some are secure (like your own) - that is if you are capable of correctly administering them. } }|> I think that there are other viable solutions. But as I said, it is }|> still possible to handle users directories on a net of 1000 workstations }|> without your ridiculous kludge. As GE has done. } } GE does it by cross-mounting all filesystems via NFS on all machines, right? }Is it really true that you have 1000 machines, with all filesystems mounted on }all of them? I find that somewhat hard to believe. Aww, you must resort to intimating that I am a liar eh? I am not sure exactly how they do it. If I had to guess, I would say that the disks of eact workstation are mounted on a main server (say on /net) and that /net is then in turn mounted on // for each workstation. Not hard to believe at all, and it is quite workable. } } In any case, you're right, it is possible to do it without explicit }mounting. That's why we're working more and more with the Andrew File System }(AFS) here at Athena. However, there are still advantages to being able to }mount filesystems arbitrarily, since many people are going to be using NFS for }a long time into the future, even if we start using AFS internally. There are also risks involved in allowing people to mount remote filesystems. } }|> I feel the authentication is unneccesarily neccesary. You have made }|> it a neccesity by putting power in the users' hands that should not }|> be there. I will not applaud you for making things more difficult. } } Um, how is it more difficult for me to have to type two commands in my }current environment to get write access to the source tree (if I am allowed }that access), while allowing to keep my entire environment, than it would be }for me to have to log into a separate source maintenance account in order to }modify the sources? } It might be a little easier for you to have to include NO NO NO commands because you are in the source group which has write access to the source files. } And let's not forget that under the Athena system, there is accountability, }because the changes made to the source tree are made by the user ID of the }user who made them, not by a special source maintenance account. To achieve }that your way, you've got to have a separate source maintenance account for }every person who's allowed to modify the source tree. } You seem to have people authorized to change source whom you do not trust (or you wouldna need to have accountability). I suggest that those peole be let go. } } You don't have to do anything of the sort. And I don't see how you ever got }the idea that you did. Authenticating to a restricted filesystem is a }one-step operation, and the authentication stays until you revoke it (or until }it expires), just as logging into a special account stays until you log out. } Being in a group that has write access to a directory tree takes NO STEPS AT ALL. Hmm, I guess that would make it alot faster tha your one-step process. }Jonathan Kamens USnail: --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
asg@sage.cc.purdue.edu (The Grand Master) (05/09/91)
In article <{#_**}@ads.com> henry@ADS.COM (Henry Mensch) writes: }background: i'm a former staff member of MIT's Project Athena and of }the Purdue University Computing Center, and am familiar with the styles }of computing available in both places. i represent only my personal }opinion with this message, and do not represent the opinion of Project }Athena or the Institute. } }asg@sage.cc.purdue.edu (The Grand Master) wrote: } }everyone out there who uses sun's automounter is doing exactly the same }thing (they are, of course, limited to the one networked file system }that is supported by the automounter). it works quite well. i suggest }you try it. As you point out later, I believe I have. } }->You do not however have any more power (in fact quite a bit less) than systems }->which now occupy about the same volume as my desk. } }consider this measure: divide the number of MIPS that your }timesharing processor provides by the number of users sharing that }processor. apply the same measure to the workstation user (remember }that only one user uses a workstation at any one time). If I have a Sequent witht the same number of processors in it as the number of users (40 max I believe) I would expect the numbers to come out pretty even - a little higher on the side of the Sequent, since it is running only 1 init for 40 people (and one inetd, and one nfsd etc) while the workstation idea has to run 40 of these for 40 people. What you also forget to mention here is what happens when only 3 people are logged into a 40 processor system. The sep workstation method takes no advantage (or very little) in only 3 of 40 workstations being used, but if only 3 people log into my 40 processor sequent, it will run much faster than a workstation. } }->You can have a large scale distributed environment without allowing }->people to mount their own directories. We have such at Purdue with the }->few centralized systems (yes, you can all sing along) with Xwindows }->terminals. } }this is not a distributed computing environment. replacing character }terminals with x terminals (did you know that the x window system came }from project athena and is an athena network service?) does not make a }distributed computing environment. } Well, then i guess I do not have the correct definition of distributed environment. The effect is basically the same though as I see it. }->We also have it here at GE where each person who has a workstation }->can still log into anny workstation and be able to access his disk without }->having to do mounting all over the place. If I want to get to a directory }->/tmp on the system a294 I do cd //a294/tmp - no problem. } }and how do you think //a294/tmp gets there? magic? maybe the }workstation *gasp* mounts a filesystem there for your use when you }make such a request. maybe they're using an automounter? May be, but I am still not allowed to decide where to mount file system's (that is preordained) and I do not have the root password. } }->It is ALREADY WORKING! } }nobody said it wasn't working. you didn't address jik's point that }this solution did not scale to hundreds of servers and thousands of }hosts. i do believe you only have a handful of sequents at purdue ... True, but that does not mean it will not scale to a larger size. As long as entombd knows what filesystem it has mounted and where it is mounted from, then the rpc instructions will tell the server what to d o about entombing } }->Oh, I like your setup even better now. Give all the users root! } }you obviously don't understand that (with single user hosts) any user }can become root with little/no effort. project athena's architecture }gets over this by making root (on a workstation) a commodity of }limited value. our users don't get root privileges on servers (where }data are kept and network services originate from). This is not neccessarily true. Please explain to me why it is impossible to keep a single user system secure. in any event, using Xterminals with some centralized system, it IS possible to keep people from becoming root. } }bruce, you might do well to have a chat with the manager of UNIX }systems at the computing center ... i know he has some clues about } Here we go again. Did you learn that tactic from Jon? Just because I disagree with you does not mean I am incapable of understanding. I know full well the merits of Athena's setup. But the biggest problems I have with Athena are 1) If I am using Xwindows, and I do something CPU-intensive, I cannot even get my pointer to move around at times, much less iconify move or size windows. With Xterminals, since the graphics are handled by the terminals processor, the function of your windowing environment is (somewhat) independant of the load on the man system. 2) Athena's setup does not take advantage of unused resources when only a few people are logged in. My machine is just as slow when I do a CPU intensive job whether all 1000 workstations are in use, or if only 100 are in use. With the method that I advocate however, My job can take advantage of those unused resources. }-- }# Henry Mensch / Advanced Decision Systems / <henry@ads.com> --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
brendan@cs.widener.edu (Brendan Kehoe) (05/09/91)
In <12074@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu writes: Henry Mensch wrote: >}this is not a distributed computing environment. replacing character >}terminals with x terminals (did you know that the x window system came >}from project athena and is an athena network service?) does not make a >}distributed computing environment. >} >Well, then i guess I do not have the correct definition of distributed >environment. The effect is basically the same though as I see it. I'd suggest you ftp pub/usenix/network_services.PS from athena-dist.mit.edu and give it a read. (If you don't have Postscript, you can do some creative vi or emacs replacments and have it in a roughly readable form.) You might have a different opinion of what a distributed system is and how Athena's net services model really cooks. (This is simply my impression -- I've never had any direct contact with them.) >}->We also have it here at GE where each person who has a workstation >}->can still log into anny workstation and be able to access his disk without >}->having to do mounting all over the place. If I want to get to a directory >}->/tmp on the system a294 I do cd //a294/tmp - no problem. >} >}and how do you think //a294/tmp gets there? magic? maybe the >}workstation *gasp* mounts a filesystem there for your use when you >}make such a request. maybe they're using an automounter? > >May be, but I am still not allowed to decide where to mount file system's >(that is preordained) and I do not have the root password. If you're on a client (and not a critical server), sure, it'd cause problems, but it would not be out of the question. >}->Oh, I like your setup even better now. Give all the users root! >} >}you obviously don't understand that (with single user hosts) any user >}can become root with little/no effort. project athena's architecture >}gets over this by making root (on a workstation) a commodity of >}limited value. our users don't get root privileges on servers (where >}data are kept and network services originate from). > >This is not neccessarily true. Please explain to me why it is >impossible to keep a single user system secure. in any event, >using Xterminals with some centralized system, it IS possible >to keep people from becoming root. Oh? And what's to stop someone from hacking into the centralized server and completely crippling *ALL* computing ability on your entire network? I can imagine some of the people on that Sequent that had Xterms hanging off of it would be mighty perturbed. While I can't say that the Athena method of distributing the server responsibilities among a bunch of machines is far better than others (I haven't the experience with both setups to make such a statement), I can say that simple logic shows how it works. (And a little reading about distributed systems in general helps, too.) >}bruce, you might do well to have a chat with the manager of UNIX >}systems at the computing center ... i know he has some clues about > >Here we go again. Did you learn that tactic from Jon? Just because >I disagree with you does not mean I am incapable of understanding. >I know full well the merits of Athena's setup. If you did, then you wouldn't be making such erratic hits at it. >1) If I am using Xwindows, and I do something CPU-intensive, I cannot > even get my pointer to move around at times, much less iconify >move or size windows. With Xterminals, since the graphics are handled >by the terminals processor, the function of your windowing environment >is (somewhat) independant of the load on the man system. 'Scuse me? How would running a CPU-intensive thing on an Athena client effect overall service? >2) Athena's setup does not take advantage of unused resources when > only a few people are logged in. My machine is just as slow when >I do a CPU intensive job whether all 1000 workstations are in >use, or if only 100 are in use. With the method that I advocate however, >My job can take advantage of those unused resources. Somehow I doubt that the system stays at precisely the same load when usage grows exponentially. -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone "Does this person look relaxed to you? Well, it's actually an experiment of Contour's new 565-E chair!"
ef1c+@andrew.cmu.edu (Esther Filderman) (05/09/91)
> Excerpts from netnews.comp.unix.admin: 8-May-91 Project Athena ( was Re: > No.. The Grand Master@sage.cc (15868) > } You asserted that we should not be writing to system source code with our > }own account. I responded by pointing out that, in effect, we are not. We > }simply require separate Kerberos authentication, rather than a completely > }separate login, to get source write access. Now you respond by saying that > }that authentication is wrong, when it is in fact what you implied we should be > }doing in the first place. > } > I feel the authentication is unneccesarily neccesary. You have made > it a neccesity by putting power in the users' hands that should not > be there. I will not applaud you for making things more difficult. > Why should I have to use a password every time I execute a command? > (I know, you don't have to for *EVERY* command - yet). What is the > purpose of separate accounts? It is so that you have to enter a > password only once. If not, you could just have open connected terminals > and require a password for any special commands (ls, vi, rm, kill). > No need for accounts. I think you misunderstand Jon's point. If I understand the way Athena works: You don't have to use a password every time, but if you want to to write to a certain area (say, system source files) you must authenticate again, once. Then you have *two* authentication instances, one valid for your "home" area and general use, one for the special security area. However, authentication is separate from login; it can be done at any time with a "log" separate similar ticket-granting process. The Andrew system is considering doing this, too. As part of a development team that uses a small portion of Andrew, and as a former Andrew system administrator, I must whole heartedly agree that this is good extra protection and security. ------------------------------------------------------------- Esther C. Filderman ef1c+@andrew.cmu.edu System Manager Library Automation Mercury Project Carnegie Mellon University They are gardeners and carpenters. They are not tomato men.
jik@athena.mit.edu (Jonathan I. Kamens) (05/09/91)
In article <12067@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> Sorry, I just don't understand how giving anyone the right to mount |> any filesystem they wish, and then giving them root access to boot |> does not at all compromise system security. Maybe you can explain this. I am not your teacher. It is not my job to teach you all about network security, Kerberos, and security in a distributed computing environment. I have given more than enough information for you to be able to learn more about these subjects on your own. Go look up "Saltzer" in the indices of the CACM for the last six or seven years. Look up also "Steiner". There are probably others, but I can't think of them off the top of my head. Also, ftp to athena-dist.mit.edu and look in /pub/usenix (athena-dist is also accessible via E-mail for people who don't have access to anonymous ftp -- send mail to archive-server@athena-dist.mit.edu with "help" in the body for more information). I have asserted that our "attach" is secure, and that root access to our public workstations does not compromise our security. I have offered to mail to anyone who asks the archives of a lengthly discussion about why root access to our public workstations does not compromise our security, and I have sent that mail to several people, including you. I feel that I have done more than my share of meeting the burden of proof on the assertions that I have made. In response, you have simply asserted that arbitrary mounting is a bad idea and that our system isn't secure. You have offered no evidence to support either of these claims. When you offer such evidence, I will discuss it. Until then, this is the last I will say about either arbitrary mounting our public workstation root access. |> Now it depends how you hook the Macs and PCs up to the network. |> And also, dunno about your PC's, put the Public PC's at Purdue |> DO have accounts for special functions, and you are not allowed |> to mess with certain things without the right authority (kind of |> a root-type idea) |> Now, if you are saying that the people in the computer dept do not |> know if they can trust the SYSADMINs in the MATH dept, well then |> you should do something about that. One of the most important tenets of computer security is that you cannot assume that anything not directly under your control is secure. This is akin to the assumption that your "opponent" who is trying to violate your security knows everything you do. As I said in my last posting, MIT has a large wide-area campus network with machines controlled by many different organizations on that network. Many of those machines are single-user Unix workstations or Macs or PCs. Our network services staff cannot spend their time watching over every one of the thousands of the machines on the network, making sure that people on it don't do anything they're not supposed to do. Therefore, we have two choices: Either we can restrict who gets network access so only machines that are directly and cleanly controlled can be on the network, or we can develop an authentication system that allows a high level of service and is not compromised by root access to machines on the network. We have chosen the latter. Purdue's security (and the security of any other Unix site that trusts root on remote machines) is dependent on every machine on the network being secure. If one machine on the network is broken into, the entire network is vulnerable. Kerberos authentication does not have that vulnerability. It was created to avoid that vulnerability, among other things. The computer industry has accepted it as a standard (for example, the OSF DCE uses it, and Ultrix 4.0 comes shipped with it, and 4.4BSD will come shipped with it as well). Your assertions that we should move back into the stone ages of trusting every machine on the Internet to be secure is therefore somewhat suspect. |> Now, if you are saying that the people in the computer dept do not |> know if they can trust the SYSADMINs in the MATH dept, well then |> you should do something about that. Security that depends on the good graces of every admin on your network is no security at all. Furthermore, it DOES NOT SCALE. The more machines you have on a network, the more people you need to run them, and the more people there are running them, the more possibility there is that someone will start playing around with root access. Kerberos avoids this problem. I wonder -- if I snarfed the entomb software from Purdue and figured out from it how the entombd stuff works and what RPC port requests are sent on, could I su to root on my workstation and send requests to an entombd at Purdue to remove somebody's files? |> A workstation can be made such that you cannot boot it from floppy |> without a passwd (in fact my PC even does this), so physical |> access is not really an excuse. A workstation, perhaps. But perhaps not a PC, or a Mac, or the portable PC that your opponent carries into a lab and plugs into your ethernet when no one's looking. One of my coworkers has an ethernet card and software in a PC that weighs ten pounds. Furthermore, the machines on our network are on the Internet. We cannot control the entire Internet. And restricting access to the Internet handicaps our users unnecessarily. I say "unnecessarily" because, as I've pointed out, the security of Kerberos makes it unnecessary for us to worry about root machines elsewhere on the Internet. |> } Users being allowed to mount other directories at will is a logical |> }extension to the ability to mount remote filesystems. Placing unnecessary |> UH - no Look. The reason that mount(2) was originally restricted to the superuser is that non-root access to it introduced security holes. If the security holes are no longer present, then the only reason for restricting mount access is no longer present, so it is logical to remove that restriction. |> }restrictions on the user is antithetical to the original design goals of Unix, |> }and furthermore, it's counterproductive. If it is technically feasible to |> }allow arbitrary filesystems to be mounted by the user, I fail to see how you |> }can call it a kludge. |> } |> It is not an unnecessary restriction. If the only reason for a restriction is for security, and if removing the restriction no longer causes security problems, then there is no reason for the restriction and it is therefore "unnecessary." This logic is not very complex. |> Again, Why don't you tell us how |> it can be that I can be allowed to mount any filesystem I choose, |> log in as root, and still not do harm to the any of your systems. |> At the very least, can I not wipe the entire root directory of the |> workstation clean? This was all discussed in my postings in alt.security. People who are interested in it can E-mail and ask me for a copy. I am not going to debate here what was already debated at length there, to the point where there was just nothing left to say. |> If I had to guess, I would say that the disks of eact workstation are mounted |> on a main server (say on /net) and that /net is then in turn mounted |> on // for each workstation. Not hard to believe at all, and it is |> quite workable. You are almost certainly guessing wrong, since (a) this is an incredibly inefficient way to accomplish the required goals, and (b) most vendors' implementations of NFS do not allow transparent exporting from one fileserver of filesystems mounted from another fileserver. It is more likely that GE is using an automounter of some sort. Automounting is a good idea, and has some advantages over the way Athena does things (although there is as much of a delay when an automounter mounts a filesystem as there is when our "attach" does it). Unfortunately, many vendors do not provide enough kernel support to make automounters work (since they usually work by attaching a process to a directory as an NFS server, and many variants of Unix don't support that), so Project Athena (which requires multiple-platform support as one of its highest priorities) decided to go another route. |> There are also risks involved in allowing people to mount remote filesystems. There are security concerns. But, as I have said from the very start, those concerns are addressable. And if you fix the security problems, then there is no longer any reason to prevent non-root mounting of remote filesystems. |> It might be a little easier for you to have to include NO NO NO commands |> because you are in the source group which has write access to the source |> files. Um, excuse me, but in message <11941@mentor.cc.purdue.edu>, you wrote: |> Is this system source code? If so, I really don't think you should be |> deleting it with your own account. In other words, your original assertion which started this whole thread is that I should not be able to write to the source code with my own account. So which is it, that I should be able to write to the source code or that I shouldn't? |> You seem to have people authorized to change source whom you |> do not trust (or you wouldna need to have accountability). I suggest |> that those peole be let go. Accountability and trust are two different things. We trust the people who work on our source code, but we still need to know who makes what changes. Accountability is a recognized necessity in virtually every branch of engineering. It's why architects sign their drawings, and why RCS and SCCS store usernames. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (05/09/91)
In article <12074@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> 40 of these for 40 people. What you also forget to mention here is |> what happens when only 3 people are logged into a 40 processor system. |> The sep workstation method takes no advantage (or very little) in |> only 3 of 40 workstations being used, but if only 3 people log into |> my 40 processor sequent, it will run much faster than a workstation. My workstation always runs fast enough for me. It has enough resources that I never have to wait for it to complete something because it's too busy to do it quickly. There is a level of performance above which improved performance is irrelevant to most applications. The typical undergraduate educational use of computers does not require supercomputer-like power to achieve its goals. The odds are that the 3 users on a Symmetry aren't going to notice that there are only three users on it, because they aren't doing anything so computationally expensive that it's relevant. For jobs where computational power IS relevant, I believe as strongly as you do that a centralized, power compute engine is useful. That is why MIT has a Cray, and why Project Athena has a DEC 9000 to which the community will eventually have access to perform computationally expensive tasks (they don't have access now because we just got it and haven't set it up yet). |> True, but that does not mean it will not scale to a larger size. |> As long as entombd knows what filesystem it has mounted and where |> it is mounted from, then the rpc instructions will tell the |> server what to d o about entombing What if it's mounted from a machine that doesn't know what the hell entombd is? The more fileservers you support, the less likely it is that all of them will be able to run entombd. Especially if some of them are not directly under your control. If I run a private workstation at MIT and want to make some file space available to people who are working on a project with me, I can make my workstation serve NFS and people can mount it on their Project Athena workstations. However, I probably won't run entombd. So what happens if someone mounts a filesystem from my workstation and then tries to "rm" a file? I certanly hope that entomb has a sane fallback mechanism for when it *can't* archive the file using RPC. Project Athena's delete doesn't have this problem. Once again, we touch on the issues of multi-platform support, scalability and complexity. |> 2) Athena's setup does not take advantage of unused resources when |> only a few people are logged in. My machine is just as slow when |> I do a CPU intensive job whether all 1000 workstations are in |> use, or if only 100 are in use. With the method that I advocate however, |> My job can take advantage of those unused resources. See the paper "Planning for Peak Loads: Limitations of Cycle-Service" by Don Davis, a Project Athena employee. It is currently in draft form, and is available for anonymous ftp (for the next week) in /pub/tmp on pit-manager.mit.edu, in the files cycle2.PS (for a PostScript version), cycle2.doc (for a text version), and cycle2.mss (for the scribe that produced the other two). It is also available via mail-server by sending a message to mail-server@pit-manager.mit.edu containing "send tmp/cycle2.mss" or "send tmp/cycle2.PS" or "send tmp/cycle2.doc". Don addresses the issue of cycle-service vs. distributed computing better than I could, so I won't try to explain it. I've included an excerpt from the paper below. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710 -- (Excerpted from paper by Don Davis) In brief, cycle-service seems to offer what time-sharing used to offer: economies of scale. For the most part, though, cycle-service is just timesharing without terminals, and it therefore suffers the disadvantages that have led the computer industry as a whole, and MIT in particular, to largely abandon timesharing. Insofar as distributed applications rely on timesharing, they are vulnerable to these same disadvantages, though distributed applications can offer novel compensations. Timesharing's biggest drawback is that it converts an uneven load pattern like Athena's into irregular response-times, which ill-serve users in surprisingly important ways. A subtler drawback is that centralized capacity is frequently idle but adds nothing to the geographical accessibility of the whole system. These drawbacks force us to avoid deploying timesharing cycle-servers unless they are evenly-loaded & fully utilized, limiting cycle-service's contribution to undergraduate education at MIT. MIT's research population presents a more uniform load-pattern, so that timesharing is probably an acceptable solution to their minicomputer-sized performance problems, like PATRAN.
rjc@oghma.ocunix.on.ca (Robert J Carter) (05/09/91)
In article <12074@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: [deleted] > >May be, but I am still not allowed to decide where to mount file system's >(that is preordained) and I do not have the root password. [deleted] >} >}->Oh, I like your setup even better now. Give all the users root! >} Note from a security type. Your missing one very important point: having access to the root password is not the problem - what causes the security hole is having ACCESS to the types of priviledges NORMALLY associated with the root account. If those priviledges arn't there, what's the big deal? Granted, it's not the standard practice - but then, you could easily argue that deviating from standards make a system more secure by making it more difficult for outsiders to figure it out. -- |=================================================================| ttfn! | Robert J Carter Oghma Systems Ottawa, Ontario | | Phone: (613) 565-2840 | @ @ | Fax: (613) 565-2840 (Phone First) rjc@oghma.ocunix.on.ca | * * |=================================================================| \_____/
cmclark@predator.rs.itd.umich.edu (Charles Clark) (05/09/91)
asg@sage.cc.purdue.edu (The Grand Master) writes: >jik@athena.mit.edu (Jonathan I. Kamens) writes: >Sorry, I just don't understand how giving anyone the right to mount >any filesystem they wish, and then giving them root access to boot >does not at all compromise system security. Maybe you can explain this. That is because you just don't understand the concept of authenticated file systems. >Now it depends how you hook the Macs and PCs up to the network. >And also, dunno about your PC's, put the Public PC's at Purdue >DO have accounts for special functions, and you are not allowed >to mess with certain things without the right authority (kind of >a root-type idea) So in other words you only allow Macs and PCs on your network that are centrally administered? That SUCKS. Furthermore you are going to have to pay for a LOAD of support and administration personnel ... AND I really don't think that your pcs are half as secure from user tampering as you apparently do. Macs and PCs are fundamentally insecure OSs. You allow me to run programs on one of them, and I WILL be able to break your security. No doubt about it. >Now, if you are saying that the people in the computer dept do not >know if they can trust the SYSADMINs in the MATH dept, well then >you should do something about that. Sure. On a campus of some 40000 (just the students, not faculty and staff) we are all just going to have to trust each other. Right. Stupid idea. >A workstation can be made such that you cannot boot it from floppy >without a passwd (in fact my PC even does this), so physical >access is not really an excuse. Right. Physical access to almost any machine, and some knowledge, will breach security. Deny reality if you want to, that is your problem. Besides, the reality is that we (and athena I assume) want to share files among many machines, right down to the macintosh in some student's dorm room. We can't assume a) centrally administered machines and we can't assume b) trusted machines. If all you want to do is share files among trusted centrally administered machines with NO other machines being allowed to connect on your subnets then fine, just MAYBE you don't need to make the assumptions that you are making and you can get away with it. But I would rather have an athena like environment than something like what I just described even if I had to use a pretty wimpy workstation instead of dialing in to your sequent thang. I'd rather deal with authentication than big brother anyday. >It is not an unnecessary restriction. Again, Why don't you tell us how >it can be that I can be allowed to mount any filesystem I choose, >log in as root, and still not do harm to the any of your systems. >At the very least, can I not wipe the entire root directory of the >workstation clean? I don't know the athena implementation enough to answer your question, but I do have enough experience to know that a system can be configured such that the user can gain NO access to files he/she shouldn't have access to and where wiping what they can as root loses no data for the administrators. Where restoring the usability of such a wiped system does not take very long (hell, I'm not sure but I don't even think a person with special priviledges would necessarily be required). So what do I the user gain by being root and doing something like that? When anyone can do it and it accomplishes nothing except annoy other peers who wish to use the system, why would I do that? >Of course you cannot assume that every machine on the network is secure. >you can however assume that some are secure (like your own) - that is >if you are capable of correctly administering them. No you can't. You can't assume a particular machine on a network is secure unless the network itself and all machines on it are secure. I don't think you've really thought about this very well, or maybe you just don't understand how these networks work. >There are also risks involved in allowing people to mount remote filesystems. Not if you don't "trust" them. And whether you believe this or not, the concept of trusted systems is almost universally agreed upon as a HUGE security risk. Especially when you don't NEED to trust them and can still accomplish the same tasks. If you'd think about it, having users able to mount remote filesystems as well as doing it the old way is an extension of functionality. So, if you can do this without breaching security, why NOT? Too flexible for ya, or what? >It might be a little easier for you to have to include NO NO NO commands >because you are in the source group which has write access to the source >files. That can be done in an authenticated manner on an authenticated file system too. Whether or not certain groups of people working on common source chose to do it that way or not is irrelevant; they may have their own extra concerns that dictate that choice and I just don't care what they are! The fact is that the distributed (at least with afs) way isn't more complicated unless you choose to make it so. And you can choose to make it so on the non-distributed way as well. IE, neither method is a particularly big win or lose in this respect. >}Authenticating to a restricted filesystem is a >}one-step operation, and the authentication stays until you revoke it (or until >}it expires), just as logging into a special account stays until you log out. >} >Being in a group that has write access to a directory tree takes >NO STEPS AT ALL. Hmm, I guess that would make it alot faster tha >your one-step process. Not really. The "one step" to authenticating can be the same one step you use to sign on. > ### ## >Courtesy of Bruce Varney ### # >aka -> The Grand Master # >asg@sage.cc.purdue.edu ### ##### # >PUCC ### # >;-) # # >;'> # ## You seem to think you are being clever and poking a ton of holes into the athena design philosophy. Give them a little bit of credit. They have been using their system for years now. They don't seem to have the security problems that you don't seem to understand how they don't have. They don't seem to have the functionality problems that you keep trying to add in to their system. It can't be from a lack of users too dumb to break into the system, this is MIT; besides you will find people capable of exploiting security problems at almost any institution. I will use an arguement that you used in support of your entomb stuff; IT WORKS. It is in use right now. The MIT guy is not talking philosophy, they have useable systems (MANY) operating like this right now. I also suggest that the people there probably use and have used more standard unix systems, but that you have shown your ignorance about the feasibility of an athena type setup in abundance. I'm not saying that athena is perfect or even the best around, just that you are not proving much besides that you don't understand it with your comments. And it isn't somebody from MIT's problem to educate you about distributed computing and authentication issues; if you want to dabate these issues it is YOUR problem to cure your own ignorance. I am SURE that with the fine libraries and computer access available at Purdue, a top notch institution in its own right (I practically flipped a coin to choses between Purdue and UofMichigan, and if Michigan didn't have a liberal arts school of great recognition on the same campus I doubt I would have come here. And oh, yeah, the other place I applied was MIT. I'm not trying to knock Purdue vs MIT or anything in any of my comments here) you will be able you find more and better information on these subjects that you will get argueing on comp.unix.admin. That is, unless what you really want is to argue, or you are totally close minded. cmc <Charles.Clark@terminator.cc.umich.edu> ps. Athena can add a couple "powerful" central type systems for dial-in or x-server access. If they don't already have such. Your system won't adequately and especially securely support the small decentralized machine or group of machines. Need I really say more?
henry@ADS.COM (Henry Mensch) (05/09/91)
asg@sage.cc.purdue.edu (The Grand Master) wrote: ->Sorry, I just don't understand how giving anyone the right to mount ->any filesystem they wish, and then giving them root access to boot ->does not at all compromise system security. Maybe you can explain this. what's so hard to understand? there is nothing of value (i.e., user data, service provision) on an workstation in an Athena-style environment. this concept is that of the dataless workstation; in this model, your workstation is like a public telephone: you authenticate to it (with your Kerberos private key/"password" for the workstation; with your calling card or other payment method to the public telephone), and you use it. there's nothing on the phone which guarantees you privileged access to any other phone user's data on the network, and the same goes for the Athena workstation. ->Now it depends how you hook the Macs and PCs up to the network. ->And also, dunno about your PC's, put the Public PC's at Purdue ->DO have accounts for special functions, and you are not allowed ->to mess with certain things without the right authority (kind of ->a root-type idea) ... and now i bring my laptop PC into a cluster (complete with network card) and plug it into the network (of course, i unplug an existing PC from the network). explain how your paradigm of PC/Mac administration solves this problem. ->Now, if you are saying that the people in the computer dept do not ->know if they can trust the SYSADMINs in the MATH dept, well then ->you should do something about that. that's not possible. there are 36 000 students at purdue university, and several thousand staff. the fact that much of the computing staff on your campus hangs together now, or when i worked there, or in the future is coincidental ... institutional politics can change all that in a second. ->Then why don't you tell us oh master of computing? you can educate yourself; there are papers available which describe the various Athena network services ... FTP to ATHENA-DIST.MIT.EDU ... look in the pub directory. ->It is not an unnecessary restriction. Again, Why don't you tell us how ->it can be that I can be allowed to mount any filesystem I choose, ->log in as root, and still not do harm to the any of your systems. ->At the very least, can I not wipe the entire root directory of the ->workstation clean? certainly. no great harm done; workstations can be reloaded in less than five minutes over the network. remember: there's nothing unique to the contents of a workstation's disk that precludes this sort of reloading/updating on the fly. ->You seem to have people authorized to change source whom you ->do not trust (or you wouldna need to have accountability). I suggest ->that those peole be let go. it's not clear how you deduced this from what Mr Kamens said. offer a rationale for this statement. -- # Henry Mensch / Advanced Decision Systems / <henry@ads.com>
asg@sage.cc.purdue.edu (The Grand Master) (05/10/91)
In article <1991May9.001907.13024@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: } I have asserted that our "attach" is secure, and that root access to our }public workstations does not compromise our security. I have offered to mail Just answer one quick question. I assume that each workstation has a disk of it's own mounted on / right? If so, can I not log into one of your workstations and rm -rf /, thus making it useless? Can I not do this for EACH AND EVERY WORKSTATION YOU HAVE? } } Therefore, we have two choices: Either we can restrict who gets network }access so only machines that are directly and cleanly controlled can be on the }network, or we can develop an authentication system that allows a high level }of service and is not compromised by root access to machines on the network. }We have chosen the latter. } You have another choice. To trust only those computers to which the user does not have physical access. }If one machine on the network is broken into, the entire network is }vulnerable. I understand this. But if you only trust computers that won't be broken into, then you are safer. What would happen if someone broke into one of your servers. Could they not delete all the files on all the filesystems for which that machine is the server? }trusting every machine on the Internet to be secure is therefore somewhat }suspect. I NEVER said anything about trusting every machine on the internet. Is there no way of telling a system to "trust" only a select few others? } }|> Now, if you are saying that the people in the computer dept do not }|> know if they can trust the SYSADMINs in the MATH dept, well then }|> you should do something about that. } } Security that depends on the good graces of every admin on your network is }no security at all. Furthermore, it DOES NOT SCALE. The more machines you }have on a network, the more people you need to run them, and the more people }there are running them, the more possibility there is that someone will start }playing around with root access. Kerberos avoids this problem. There still must be SOME people that have a top level of access. What is to stop them from doing whatever they want? } } I wonder -- if I snarfed the entomb software from Purdue and figured out }from it how the entombd stuff works and what RPC port requests are sent on, }could I su to root on my workstation and send requests to an entombd at Purdue }to remove somebody's files? I doubt it, since the entombd probably knows to trust only a few other systems. } }|> A workstation can be made such that you cannot boot it from floppy }|> without a passwd (in fact my PC even does this), so physical }|> access is not really an excuse. } } A workstation, perhaps. But perhaps not a PC, or a Mac, or the portable PC }that your opponent carries into a lab and plugs into your ethernet when no }one's looking. One of my coworkers has an ethernet card and software in a PC }that weighs ten pounds. Are you telling me that you cannot tell your systems to trust just a selected list of other systems? Are you saying that your system must trust everyone or noone and that there is no medium? } } Furthermore, the machines on our network are on the Internet. We cannot }control the entire Internet. And restricting access to the Internet handicaps }our users unnecessarily. I say "unnecessarily" because, as I've pointed out, }the security of Kerberos makes it unnecessary for us to worry about root }machines elsewhere on the Internet. } Again, Are you telling me tha You cannot tell your system to trust prep.ai.mit.edu and not trust ypig.stanford.edu ? Why not? } } It is more likely that GE is using an automounter of some sort. }Automounting is a good idea, and has some advantages over the way Athena does }things (although there is as much of a delay when an automounter mounts a }filesystem as there is when our "attach" does it). Unfortunately, many }vendors do not provide enough kernel support to make automounters work (since }they usually work by attaching a process to a directory as an NFS server, and }many variants of Unix don't support that), so Project Athena (which requires }multiple-platform support as one of its highest priorities) decided to go }another route. } I don't think so then. If I do a listing of // , and say the directory for the system a333 is not listed, then I do a cd //a333, there is no waiting period. I have never experienced a waiting period. } }|> It might be a little easier for you to have to include NO NO NO commands }|> because you are in the source group which has write access to the source }|> files. } } Um, excuse me, but in message <11941@mentor.cc.purdue.edu>, you wrote: } }|> Is this system source code? If so, I really don't think you should be }|> deleting it with your own account. } }In other words, your original assertion which started this whole thread is }that I should not be able to write to the source code with my own account. So }which is it, that I should be able to write to the source code or that I }shouldn't? Let's try again. Maybe you should get a dictionary first and look up the words "write" and "delete~. Hmm, they are different aren`t they? I see no problem with altering the system source code to a program from your own account. I just feel that it should be a little harder to delete stuff (so you don't do it accidently, etc). } }-- }Jonathan Kamens USnail: Some final thoughts. I can see that Athena is a worthwhile setup. I know that it is one of the possible worthwhile solutions. It has alot of merit, and I can see why some people would prefer it. I understand now that letting users mount filesystems is safe, though I still disagree with giving them root (see my comment on this near the beginning of the article). I see why some people like distributed computing. But Jon conveniently failed to respond to my major gripe with distributed computing. Resources go unused more often. So I will state it again in case you all forgot: If I am doing something CPU intensive on a workstation, I gain no added benifit from the fact that only 1/10 of the workstations are in use. I also will see a significant reduction in the speed of my window operations, since the same CPU is handling them and the intensive task. If I have a some centralized computers though, I now DO benifit when only 1/10 of the maximum number of people are logged in. And my windows will not be nearly as affected, since they are controlled bu a CPU that is not encumbered with a heavy Job. Just so you know. I do not consider Jon stupid in any way. He is very intelligent, and I respect his opinions, which is exactly why I have continued this discussion - If I did not care about his opinion, I would never have responded to him in the first place. However, It is not right to call ME foolish, or ignorant simply because i choose to disagree with him. Maybe Jon has not had some of the problem s I have with workstations. I often am running CPU and disk intensive jobs. Unfortunately, this sometimes limits me to one thing at a time, since the single processor is unable to handle a huge load. Working on a system that had 40 || processors however would alleviate this problem in the majority of cases. Jon's opinion is valid. But that does not mean that my opinion is not. --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
jik@athena.mit.edu (Jonathan I. Kamens) (05/10/91)
(I am omitting responses to points which have already been dealt with in previous postings.) In article <12112@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> I understand this. But if you only trust computers that won't be broken into, |> then you are safer. What would happen if someone broke into one of your |> servers. Could they not delete all the files on all the filesystems for which |> that machine is the server? What would happen if someone broke into one of your Symmetries? Could they not delete all of the files on all the filesystems for which that machine is the server? Project Athena's service machines (e.g. file servers, authentication servers, mail servers, etc.) are secured just as your machines are. |> } Security that depends on the good graces of every admin on your network is |> }no security at all. Furthermore, it DOES NOT SCALE. The more machines you |> }have on a network, the more people you need to run them, and the more people |> }there are running them, the more possibility there is that someone will start |> }playing around with root access. Kerberos avoids this problem. |> |> There still must be SOME people that have a top level of access. What is |> to stop them from doing whatever they want? There are less than five people at Project Athena with access to the authentication server. That number can stay constant no matter how many machines are added to our network. The number of admins of individual systems may grow as systems are added, but that does not decrease our security since we do not trust those individual systems. On the other hand, the setup you are advocating trusts systems that are added. That means that every admin is trusted. How many people have root access to any of your machines, Bruce? There must always be some level of trust, because you've got to have someone running things. The point is to minimize the amount of trust required. As I said, trusting every admin does not scale, while trusting a very small, constant number of people no matter what the size of the network does. |> But Jon conveniently failed to respond to my major gripe with |> distributed computing. Resources go unused more often. The paper I referenced in my last point addresses this "major gripe," which is why I referenced it. Did you bother to read it? It's only a few pages long. |> If I am doing something CPU intensive on a workstation, I gain no |> added benifit from the fact that only 1/10 of the workstations |> are in use. I also will see a significant reduction in the speed of |> my window operations, since the same CPU is handling them and the |> intensive task. If you are doing something so CPU intensive that your workstation slows down, then either (a) get a better workstation, or (b) use a compute server such as a Cray or DEC 9000. As I pointed out in a previous posting, Project Athena users *do* have access to those resources if they need them, which means that we have the best of both worlds. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
cmclark@predator.rs.itd.umich.edu (Charles Clark) (05/10/91)
asg@sage.cc.purdue.edu (The Grand Master) writes: >Just answer one quick question. I assume that each workstation has a >disk of it's own mounted on / right? If so, can I not log into one of >your workstations and rm -rf /, thus making it useless? Can I not do >this for EACH AND EVERY WORKSTATION YOU HAVE? So what? That breaches no security. And you can only do that on the public workstations, not each and every one. And you need to be there physically to do it. And every student that is trying to get work done will beat you silly or to a pulp whichever comes last if they see you doing something this stupid to machines they are wanting to use. There is no gain to doing this. And the machines can be brought back up in orginal condition (because / contains nothing unique to the workstation eh) in minutes. Like I said, you could do this but so what, who is going to under these conditions. Furthermore have they had this problem in their years of operating this way? No. Doesn't this weigh in more than your arguements? Yes. >You have another choice. To trust only those computers to which the user does >not have physical access. How? Trust them because they claim to have a name or ip number that you have in a list? This is fundamentally insecure, because both the ethernet and TCP/IP protocols are insecure in this respect, unless you allow absolutely NO other machines besides the trusted ones on your networks. Not gonna happen. >I NEVER said anything about trusting every machine on the internet. Is there >no way of telling a system to "trust" only a select few others? No there isn't. That is what we are trying to tell you. Without an authentication scheme, trusting machines by name or number is very small security. >Again, Are you telling me tha You cannot tell your system to >trust prep.ai.mit.edu and not trust ypig.stanford.edu ? >Why not? Sure you can tell it that. But the thing is, non-trustworthy machines exist all over the internet that can fake being prep.ai.mit.edu or anything else you want. Especially if they can plug in on the same subnet. cmc
peter@ficc.ferranti.com (Peter da Silva) (05/10/91)
In article <12049@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: > In article <1991May7.224644.16951@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > }I suggest you try to find out more about Athena. > I am attempting to do just that so that I have an example of how *NOT* > to administrate a network. I suggest you go get the appropriate Usenix proceedings (I think it was one of the Dallas Usenix Conferences) and look Athena up. It's a fascinating design. It's not a "network" per se, but rather a distributed operating system like Amoeba, Plan 9, or Andrew... albeit with a somewhat less agressive redesign of UNIX than these systems. It doesn't provide full UNIX semantics (but then either do Andrew or Amoeba, and Plan 9 is a different kind of flying altogether), but it's pretty much arbitrarily scalable. > can still log into any workstation and be able to access his disk without > having to do mounting all over the place. If I want to get to a directory > /tmp on the system a294 I do cd //a294/tmp - no problem. We have a similar network at Ferranti, called OpenNET (though it's closed: intel only... no others need apply). It's nice, but it's not a distributed system. An Athena or Andrew system would be nice. > Where you get this I have no idea. I want to see your workstations if they are > as powerful as a Sequent Symmetry. Pretty damn good workstations I guess. Well, they started with PC/RT and Microvaxen. I have no idea what they have now. > Oh, I like your setup even better now. Give all the users root! Very > tidy, and secure. It is, because on Athena root doesn't mean anything. You can do anything you want on that workstation, but you can't touch anyone else without the right tokens. And even a snoopy program on the WS wouldn't help, because they expire those tokens. > elaborate autentication system - but tell me, if you dinna let your > users have root privs would you NEED the elaborate authentication > system? If users can touch the metal, they can get root privileges. That is a constant. They can even snoop the net and grab everyone else's data. If you're depending on root protection to keep your network secure you're asking for trouble. > And giving away root privs is. What is the purpose of having semarate > accounts then? Or do you have to give some kind of Kerberos authentication code > for every damn thing you do? Yep. Of course it's transparent to the user once they've actually logged onto Kerberos. > Oh, you do not support rlogin - ic. > So tell me, how do I get at my files from a remote location? You mount it. > Why should I have to use a password every time I execute a command? You don't. And you won't have to. You really need to check out Kerberos and Project Athena. It's a really neat system. As are the other distributed computing environemnts out there. I don't know if Jonathan's claim that Athena was the first really holds water (Andrew was pretty early, too), but it *is* an influentual one. And Jonathan... you could do with a bit of chilling out too. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/10/91)
In article <12067@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: > And also, dunno about your PC's, put the Public PC's at Purdue > DO have accounts for special functions, and you are not allowed > to mess with certain things without the right authority (kind of > a root-type idea) How do you implement that? Since DOS does not provide any protection, I can write a simple program that reams the whole "account" system out of there. > At the very least, can I not wipe the entire root directory of the > workstation clean? So what if you do? That's a denial of service attack equivalent to putting superglue in the ethernet connector so you can't plug it in. Why would you do either? One workstation is down until the system can be reinstalled on it... -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
cgd@ocf.Berkeley.EDU (Chris G. Demetriou) (05/10/91)
>I don't think so then. If I do a listing of // , and say the directory >for the system a333 is not listed, then I do a cd //a333, there is >no waiting period. I have never experienced a waiting period. this sounds an *AWFUL* lot like the Apollo system for doing remote filesystem access... are you using apollos? if so, you should have forgotten about the concept of security a long time ago... after all, they're "personal workstations" <sigh> cgd
torek@elf.ee.lbl.gov (Chris Torek) (05/10/91)
In article <12112@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: >Just answer one quick question. I assume that each workstation has a >disk of it's own mounted on / right? If so, can I not log into one of >your workstations and rm -rf /, thus making it useless? Can I not do >this for EACH AND EVERY WORKSTATION YOU HAVE? I have no idea whether these workstations are `diskless' and use a remote disk or have a local disk, but the principle is the same. The answer is `yes'. You can also, of course, walk in with a sledgehammer and bust each and every workstation into a million pieces. Either one will get you some kind of disciplining, if you are caught. Both actions are semantically (if not monetarily) equivalent: in both cases you cost the support staff some time/money to fix/replace the equipment, and nothing else. As to networks and trust: >You have another choice. To trust only those computers to which the >user does not have physical access. The basic problem here is that the network itself is physically accessible as well, and such access can be nearly untraceable. Your average Ethernet or fiber optic cable can be `wiretapped' without too much difficulty and with little chance of detection. If this is done, sessions can be recorded and/or played back, and the `tapping' machine can stand in the stead of another, previously existing machine. The Athena security system provides a variable amount of defense against this sort of intrusion. If you wiretap and collect someone's tickets, you can use playback methods to gain access for the duration of the ticket. If sessions themselves are encrypted (this is quite expensive in terms of CPU time, hence is rarely done, at least outside Athena---probably inside as well) the windows are narrow and security is relatively high. If the sessions are not encrypted you can, of course, get quite a bit more information. >I NEVER said anything about trusting every machine on the internet. Is there >no way of telling a system to "trust" only a select few others? Unfortunately, the answer is a qualified `no', because any machine can (within various limitations) impersonate any other. The limitations are largely to do with routing issues. There are schemes galore for improving this sort of security; the Athena Kerberos software has the advantage of being relatively simple, `known largely to work' and, not least, free. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
henry@ADS.COM (Henry Mensch) (05/10/91)
asg@sage.cc.purdue.edu (The Grand Master) wrote:
->jik@athena.mit.edu (Jonathan I. Kamens) writes:
->} I have asserted that our "attach" is secure, and that root access to our
->}public workstations does not compromise our security. I have offered to mail
->
->Just answer one quick question. I assume that each workstation has a
->disk of it's own mounted on / right? If so, can I not log into one of
->your workstations and rm -rf /, thus making it useless? Can I not do
->this for EACH AND EVERY WORKSTATION YOU HAVE?
ever hear of:
-> boot media?
-> booting over the network??
the contents of the hard disk can be reinstalled off boot media or
over the network in less than five minutes.
yeah, sure, you can do this, but it's not of much consequence.
--
# Henry Mensch / Advanced Decision Systems / <henry@ads.com>sfreed@ariel.unm.edu (Steven Freed CIRT) (05/11/91)
In article <12112@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: > I NEVER said anything about trusting every machine on the internet. Is there > no way of telling a system to "trust" only a select few others? O.K., Let's take this very simple example: Let's say that foobar.cc.purdue.edu is one of your so-callled "trusted" systems. One night foobar crashes, or better yet, you announce that on Thursday, June 23 at 18:00 you are going to take foobar down for an upgrade or maintenance. I sit in my dorm room, or in the MATH dept. or any where else on the net with my trusty little cpu of brand X with an ethernet card. as soon as I see foobar is down, I bring my little box on line as ...........foobar.cc.purdue.edu!!!!!! Now, tell me how secure your system is. -- Steve. sfreed@ariel.unm.edu
asg@sage.cc.purdue.edu (The Grand Master) (05/11/91)
In article <1991May10.173941.8778@ariel.unm.edu> sfreed@ariel.unm.edu writes: } }In article <12112@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: } }> I NEVER said anything about trusting every machine on the internet. Is there }> no way of telling a system to "trust" only a select few others? } }O.K., Let's take this very simple example: } }Let's say that foobar.cc.purdue.edu is one of your so-callled "trusted" }systems. One night foobar crashes, or better yet, you announce that on }Thursday, June 23 at 18:00 you are going to take foobar down for }an upgrade or maintenance. I sit in my dorm room, or in the MATH dept. }or any where else on the net with my trusty little cpu of brand X with }an ethernet card. as soon as I see foobar is down, I bring my little }box on line as ...........foobar.cc.purdue.edu!!!!!! } }Now, tell me how secure your system is. Very - If I have foobar.cc.purdue.edu connected via a direct line of some sort. As long as I tell my system to trus foobar ONLY when it is soming from a dedicated, hard-wired port, then all is well, and any requests you make will be rejected. Bruce > >-- > >Steve. sfreed@ariel.unm.edu --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
brendan@cs.widener.edu (Brendan Kehoe) (05/11/91)
In <12184@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu writes: >}Now, tell me how secure your system is. > >Very - If I have foobar.cc.purdue.edu connected via a direct line of >some sort. As long as I tell my system to trus foobar ONLY when it is >soming from a dedicated, hard-wired port, then all is well, and any requests >you make will be rejected. And how often do you have hard-wired ports, in all practicality? -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone "Does this person look relaxed to you? Well, it's actually an experiment of Contour's new 565-E chair!"
jik@athena.mit.edu (Jonathan I. Kamens) (05/13/91)
In article <12184@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> Very - If I have foobar.cc.purdue.edu connected via a direct line of |> some sort. As long as I tell my system to trus foobar ONLY when it is |> soming from a dedicated, hard-wired port, then all is well, and any requests |> you make will be rejected. How exactly do you connect a machine to a TCP/IP network on a "direct line?" And how exactly do the other machines on that network tell that they're talking to the machine on the "direct line" and not to some other machine on the same subnet? -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
asg@sage.cc.purdue.edu (The Grand Master) (05/13/91)
In article <1991May9.201346.28483@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: } What would happen if someone broke into one of your Symmetries? Could they }not delete all of the files on all the filesystems for which that machine is }the server? } } Project Athena's service machines (e.g. file servers, authentication }servers, mail servers, etc.) are secured just as your machines are. Exactly my point. If the main computers are setup correctly, then they are just as secure as your servers. } } On the other hand, the setup you are advocating trusts systems that are }added. That means that every admin is trusted. How many people have root }access to any of your machines, Bruce? I never said that Purdue was the ideal setup first of all. I have described what I think is ideal. Several powerful centralized systems which trust each other only because they are "hard-wire" connected. } }|> But Jon conveniently failed to respond to my major gripe with }|> distributed computing. Resources go unused more often. } } The paper I referenced in my last point addresses this "major gripe," which }is why I referenced it. Did you bother to read it? It's only a few pages }long. Well now you regerenced that in a later response to my same article. I am not used to people responding to the same article twice. I read your first response, and figured you had said all you wanted to say about that one and then responded to that. Not until later did I come upon your later post with the reference. } }|> If I am doing something CPU intensive on a workstation, I gain no }|> added benifit from the fact that only 1/10 of the workstations }|> are in use. I also will see a significant reduction in the speed of }|> my window operations, since the same CPU is handling them and the }|> intensive task. } } If you are doing something so CPU intensive that your workstation slows }down, then either (a) get a better workstation, or (b) use a compute server }such as a Cray or DEC 9000. As I pointed out in a previous posting, Project }Athena users *do* have access to those resources if they need them, which }means that we have the best of both worlds. I DO NOT WANT A COMPUTE SERVER. I want to be running interactive. I do NOT want to make up jcl's. Jon, some of the PLOTS I do are enough to bog down a fairly good workstation to the point where it cannot operate the windows. My seetup elimintes that problem since a different CPU is handling the windows than the CPU doing the calculations. } }Jonathan Kamens USnail: Bruce --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
metzger@watson.ibm.com (Perry E. Metzger) (05/14/91)
In article <13043@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >The basic problem here is that the network itself is physically >accessible as well, and such access can be nearly untraceable. Your >average Ethernet or fiber optic cable can be `wiretapped' without too >much difficulty and with little chance of detection. If this is done, >sessions can be recorded and/or played back, and the `tapping' machine >can stand in the stead of another, previously existing machine. Not to contradict Chris, who knows a whole lot more than I can ever hope to, but... 1) Fiber is hard to tap. Well, not that hard, but harder than cable. and.. >The Athena security system provides a variable amount of defense >against this sort of intrusion. If you wiretap and collect someone's >tickets, you can use playback methods to gain access for the duration >of the ticket. 2) You CANT record and play back tickets! The tickets are sent back to the user via a secure channel (they are encrypted in the users password!), and even if you see an instance of a ticket wizzing by on the network, you have only a couple of seconds to replay it as I recall, PLUS it would probably not work anyway if the service is keeping track of request id's, or so I recall. The REAL risk is someone broke in to your workstation and grabs your tickets when they get stored on your local machine. Perry
jlee@sobeco.com (j.lee) (05/14/91)
In <%M_*_#*@ads.com> henry@ADS.COM (Henry Mensch) writes: >there is nothing of value (i.e., user data, service provision) on an >workstation in an Athena-style environment. this concept is that of >the dataless workstation; in this model, your workstation is like a >public telephone: you authenticate to it (with your Kerberos private >key/"password" for the workstation; with your calling card or other >payment method to the public telephone), and you use it. there's >nothing on the phone which guarantees you privileged access to any >other phone user's data on the network, and the same goes for the >Athena workstation. I have read several of the Kerberos papers, but two questions remain: (1) Sure, the central servers don't have to trust my workstation, but I (as an end-user) do. How can I be sure that when I walk up to a workstation with a login prompt that I can trust the "login" code? Workstations are NOT like telephones in that they are smart devices and can easily be reprogrammed. (2) End-users authenticate themselves by typing in a password. How do servers authenticate themselves? Is the service password compiled into the binary, and if so, how do you protect both the binary and the source? >you can educate yourself; there are papers available which describe the >various Athena network services ... FTP to ATHENA-DIST.MIT.EDU ... >look in the pub directory. If the answers to these questions really are in the papers, feel free to tell me so. However, the last time I looked into Kerberos, these issues were not covered in the papers I read. Jeff Lee jlee@sobeco.com || jonah@cs.toronto.edu
peter@ficc.ferranti.com (Peter da Silva) (05/15/91)
In article <12262@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: > I DO NOT WANT A COMPUTE SERVER. I want to be running interactive. I do > NOT want to make up jcl's. Why would you need to make up "jcl" to use a compute server? Try this: $ rlogin compute-server Password: $ export DISPLAY=myworkstation:whatever $ big-job $ exit In addition, I'd like to ask you what lead you to believe that delete would delete a directory that contained undeleted files. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (05/16/91)
asg@sage.cc.purdue.edu (The Grand Master) writes: | } Project Athena's service machines (e.g. file servers, authentication | }servers, mail servers, etc.) are secured just as your machines are. | Exactly my point. If the main computers are setup correctly, then they are | just as secure as your servers. This is true at the limit of setup effort, but may not be true in practice. There are, broadly speaking, two levels of protecting a resource on a machine (such as a password database or an essential service): - Don't allow unauthorized or unprivledged users on the machine in the first place. - Protect the resource so that unauthorized users on the machine cannot harm it. In practice and with current Unixes, the first is easier and "more secure" than the second. If my machine refuses all network logins and can only be logged onto from the locked-away console terminal, it is less open to outside attacks and OS file-protection bugs and pty bugs and so on. Unix is no longer a clean and obviously secure system, and you need to take this uncertainty into account when worrying about overall security. -- "This Vi mode "feels" like Vi to me; it drives me nuts in the ways that I am used to Vi driving me nuts." - Brian Fox cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks