shap@polya.Stanford.EDU (Jonathan S. Shapiro) (11/27/88)
Bravo, Percarlo! In article <267@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Many sys admins with a delusion of "management" have a gut instinct >that the best way to achieve something is by inconveniencing >users and imposing restrictions. Well, not only this is unnecessary, it >is also quite ineffectual, because it is easily circumvented in most >cases, and certainly in the one this article is about. In practice, this is exactly true. The largest source of security holes in "secure" systems is the administrators. In addition to not paying attention to security, they have a bad habit of asserting that they know better and building their own security holes. How many of you UNIX administrators *don't* have some program that gets you root priviledges without a password on the basis of who you are logged in as? >As somebody pointed out, the first thing new >*users* are told at MIT is the root password and yet security is >probably better there than in a network in which users cannot use the >suid/sgid facility... This raises an important but often missed point. Far too many users don't appreciate what an out of control program can do. On the whole, the vast majority of security breaks are not malicious - they are acts of curiosity. Giving out the root password, in environments where this is appropriate, both removes the incentive for such acts by the curious and makes them aware of the power and responsibility of such priviledges. It also encourages them to learn about system administration, which tends to result in more responsible and better educated users. Finally, it personalizes the computer as a domain over which they have control, and therefore, interest. People with the root password will often take active measures to *protect* their systems from damage, and they become vital resources because of their knowledge in times of crises. Yes, I understand fully that this isn't appropriate in all environments. In the most productive development environments I know about, everyone has the root password to at least their own machine, and network-mounted file systems use uid mapping to prevent damage to critical resources. In addition, a non-development, "production" machine is used to supply truly critical resources. It works very very well, and enables a development group to customize their environment for maximal development effectiveness. Jon Shapiro
lkw@solaria.csun.edu (Larry Wake) (06/10/89)
As J Greely said, there are two categories of security features that need to be addressed: inadvertant holes, and "design features." I've reported the holes I've found to NeXT, and don't see any reason to air those here. The features, since they're more subjective, I'll discuss. First and foremost of the design features that needs to be fixed is the su hack. This must go. There is no reason for it to exist, and several compelling reasons for it to be removed. Second would be BuildDisk. A compromise solution might be make it only executable by owner and group, and change it to group staff. Since "me" comes group staff by default, "me" would be able to run it out of the box, but access to it can be controlled by virtue of who has membership in group staff. Third would be Preferences. Rather than changing its suid status (this is supposed to be a system you don't have to be a UNIX guru to control, right?), there should be a default settable by root that would control whether mortals can muck with the date and boot device. As I've mentioned to NeXT, the date interface is especially dangerous, as it's been made fun 'n' easy to play with, which accounts for all kinds of bizarre dates set on our public machines. I think my parenthetical comment above should be explored a little further. The design philosophy of the NeXT seems to be "provide UNIX power to non-gurus." This is great, and NeXT has succeeded in this to a greater degree than any other box I've seen yet. *However*, there seems to be a new and fallacious corollary to this philosophy, that "non-gurus don't need security." As has been pointed out, this is for the most part wrong. If NeXT really is targetting universities, and if they're serious about that Ethernet connector on the back of the box, security must be considered as one of the most important requirements that their potential buyers will demand. The point is that security and ease-of-use are not mutually exclusive goals, and that it is as wrong as wrong can be to shrug it off with "well, if they want security, they must be gurus and they can hack around on their own until it's fixed." In fact, it should be painfully clear that the people who know the least about security are the ones who need security features the *most*, and they need them to be provided by the vendor in an *easy-to-use form*. "Oh, now you've found *that* hole? Congratulations! Since you've found it, now we'll tell you how to fix it. Just change the suid bit--uh, no, you type 'c-h-m-o-d...' What do you mean, 'the Name Expansion box opened'? You have to do this from the Terminal window. Just double click on the thing that looks like a little terminal; either button, yes. Why do you think we put two buttons on the mouse, so they'd do *different* things? ...it's not there? Then you have to go to the NextApps directory -- no, the X and T aren't capitalized this time, don't ask me why...OK, Terminal's launched? Now, try chmod. 'Not owner'? Oh, you have to su to root. Just type in the password of the guy sitting next to you..." In all seriousness, this is not the way to treat security. I understand that this is 0.9, but this is why we *have* 0.9: so we can road test it and maybe have some influence over what 1.0 will look like. 0.9 for the most part brought many good things into the NeXT environment; I'm really looking forward to a similar leap at 1.0. -- Larry Wake, CSUN Computer Center lkw@csun.edu Northridge, CA 91330 csun!lkw Am I the only one who thinks Robert Palmer is singing "This cantaloupe is mythical"?