ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/May-Jun/Security

This is Security in view mode; [Up]


Date: Sun 09-Jun-1989 17:31:37 From: Unknown Subject: Security 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.

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.