Newsgroups: comp.unix.admin Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!umich!terminator!predator.rs.itd.umich.edu!cmclark From: cmclark@predator.rs.itd.umich.edu (Charles Clark) Subject: Re: Project Athena ( was Re: Non Destructive Version of rm) Message-ID: <1991May9.081725.20296@terminator.cc.umich.edu> Sender: usenet@terminator.cc.umich.edu (usenet news) Organization: U of Michigan, ITD Research Systems References: <12049@mentor.cc.purdue.edu> <1991May8.174603.26309@athena.mit.edu> <12067@mentor.cc.purdue.edu> Distribution: na Date: Thu, 9 May 91 08:17:25 GMT 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 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?