hobbes@caen.engin.umich.edu (Steven J Mattson) (06/09/89)
From article <4985@umd5.umd.edu>, by feldman@umd5.umd.edu (Mark Feldman): > It seems to me that most of the people complaining about NeXT security are > somewhat frustrated, but for the most part calm. The frustration comes from > liking many aspects of the NeXT, but knowing that the next load of > workstations to be purchased will be from Sun, DEC, or someone else, because > NeXTs cannot be secured in a hostile (or just ignorant) environment. > Making it easy to accidentally clobber a machine is nothing to brag about. > The ability for any user to easily and arbitrarily change the date and time > -- functions as important to the security, integrity, and correct operation > of a UNIX box as file permissions -- is a mis-feature. Joe user probably > doesn't know the consequences of this action. If a user is allowed to make > such a mistake without being forced to become root (knowing that actions > taken as root can have severe consequences), he may injure himself, other > users on the same machine, and the aftermath will eventually get back to me > as a NeXT support consultant. > It's not so much ``my rules'' as common sense. I'm not one for leaving the > keys in the ignition and the engine running when I'm away from my car. Most > people aren't. Why is it NeXT's default? If somone knows enough about his > environment, let him remove the safeguards, but don't make it the default. You'd think with all of the possibilities available people in this newgroup -- either directly here given that lots of people from Next participate or through their sales reps -- to get their problems aired, that someone would be able to civilly discuss their difficulties without baselessly ripping into the company for self-gratification. This whole issue of security has read like a study in ineptitude. Yes, I will back this up: 1) Next is trying to produce a machine with native unix that has the ease of use of a Macintosh. Not an easy task, take A/UX for an example if you care to, I don't. Other than the lack of software, they've done a fair job so far, but if people would stop flaming long enough to point out problems than maybe it could be better. For example, allowing anyone who feels like it to change the system time on a unix machine is incredibly stupid, I agree. So tell Next to take it out or at least protect it from casual studipity. But as another example, allowing BuildDisk to run suid is not quite as stupid, if your system is standalone on someone's desk. If you want to be able to initialize a disk, pop it in and do it. Preventing people from building the disk they're currently booted off of is more a concern. Next has consistently said that they want to hide the unix from people as much as possible. Their machines come configured for standalone use, with *absolutely nothing* restricted from the user who sets up the machine. If this is how you leave the machine (and if you're not on a network, why not?) then for the most part it is no easier or harder to trash than a Mac. 2) Even when on a network, Nexts are still set up to make network configuration for a small homogeneous network as painless as possible. I think this is as it should be if Joe Prof. is going to buy one. Do you think he has enough knowledge of unix to get the thing up and running in a massive heterogeneous environment anyway? Not the Profs around here. No unix box was ever plug and play out of the case. Gee, maybe that's why they wanted to have campus support people? 3) There are two sets of people losing their heads consistently in this group. The first group can't wait to get their hands on sources so they can see which calls Next used to write stuff, and then they'd probably complain about the order of parameters or something of equal redeeming value. They said it wasn't going to happen unless you had a good reason, find one. The second set can't flip an suid bit to save their skins. If the machine doesn't come up perfectly for their environment as a default, then screw it and its relatives for a thousand generations. Maybe if some of the overunixed people smashed their heads into those of the underunixed we could all get some work done. Another example: Using the same software techniques that Sun administraters use to prevent access to the singleuser boot, we've had Nexts in PUBLIC labs for people to try out since late December. Every once in a while someone would have to go reboot one (a 0.8 trademark) but the security of the machine or the network was never an issue. Some of us even reported the need to be able to protect this more easily to those Next people who kept coming around asking what our problems were. 4) Need I remind you all that we're talking about a BETA machine here. People seem to keep forgetting that the software release they're running has a major version number of "0". As I see it, the whole point of this massive and unprecedented beta test was to help them make a "final product" that would better meet the needs of their market than anything that exists so far. There is no final product yet people. People very eager to have one here on campus have asked me whether or not they should buy a Next now. I have consistently said, "No. Wait until 1.0 comes out and the machine is stable, or if you need something now, go ahead and buy someone else's." There is nothing tragic about recommending that a user buy something that works. If you're all as hot on the next as you say you, then maybe you could spend some more time beta testing and less time flaming to make 1.0 a better final product. In the mean time all of you eager beavers could be looking for things that might potentially harm the system and informing CALMLY both Next and the rest of us so that we can take steps to protect ourselves from disaster. I think I've stated my point emough here. You all have a chance to make a difference, but instead you spend all day flaming Next for their supposed stupidity with comments that if you took the time to think about it you'd realize something: Everything you say either applies to others vendors as well, or is a complaint about an attempt Next has made to solve problems that other vendors have as givens. I've been just as pissed at the machine as any of you on occassion, but they've said they're going to fix things so I report 'em and put up workarounds for the users here. Real tough to do. Save your flames for worthwile problems. -Steve Mattson Computer Aided Engineering Network These are MY opinions, University of Michigan if you don't agree with them, hobbes@caen.engin.umich.edu piss off.
avie@wb1.cs.cmu.edu (Avadis Tevanian) (06/09/89)
From article <4985@umd5.umd.edu>, by feldman@umd5.umd.edu (Mark Feldman):
> Making it easy to accidentally clobber a machine is nothing to brag about.
When we ship a machine, we need to make sure that it works for a standalone,
naive user. This is why applications like BuildDisk and Preferences are
shipped setuid. If you need to add a machine to an administrative domain
under your control, and you would like to eliminate the potential problems
these applications cause, then you must sanitize the machine.
For example, it is trivial to disable the setuid bit on Preferences... it
is already set up to handle this and allows a user to set anything except
those things that require root access (date/time/boot device/...)... at
least in 1.0 (I'm not sure about 0.9). If you are afraid of someone logging
into a machine and doing a BuildDisk on it, then you remove the BuildDisk
application.
There are always going to be applications that seem to be overly privileged
as shipped --- this is necessary to handle that naive, standalone user.
I think it would be valuable; however, to get feedback on any area where
system administrators feel they can not protect their system. I will then
attempt to make sure that we can find solutions to get into 1.0. Remember,
though, you have to be willing to go to the effort to turn off a setuid
bit here or there (or some similar thing).
I also think it would be very valuable to put together a list of things
that a system administrator might want to do (e.g., disable setuid on
Preferences, remove BuildDisk, ...) and make it available to other system
administrators. Perhaps someone out there would like to be the collection
point for this.
Feel free to send me information along these lines at avie@next.com.
--
Avadis Tevanian, Jr. (Avie)
Manager, System Software Group / Chief Operating System Scientist
NeXT, Inc.
avie@cs.cmu.edu or avie@NeXT.com
-- jgreely@lisa.cis.ohio-state.edu (J Greely) (06/09/89)
In article <43b721a8.19ac2@wasp.engin.umich.edu> hobbes@caen.engin.umich.edu (Steven J Mattson) writes: >From article <4985@umd5.umd.edu>, by feldman@umd5.umd.edu (Mark Feldman): [Mark's clear, reasonable discussion deleted] >You'd think with all of the possibilities available people in this newgroup -- Huh? >either directly here given that lots of people from Next participate or >through their sales reps -- to get their problems aired, that someone would >be able to civilly discuss their difficulties without baselessly ripping >into the company for self-gratification. Would you mind clarifying that? "Baselessly ripping into the company for self-gratification" might sound pretty, but I haven't the slightest idea what you're referring to. If you want civil discussions of problems, I could post the twenty-odd pages of bug reports I've sent since 0.9 arrived, and lots of people could go "Yup, I seen that one too." > This whole issue of security has >read like a study in ineptitude. Yes, I will back this up: Good thing, too. Otherwise I'd start questioning where the "ineptitude" is coming from. This "issue of security" is rather important to a large number of people. >1) Next is trying to produce a machine with native unix that has the ease > of use of a Macintosh. Well, that's one way of putting it. The pithier expression bandied about is "a networked Mac with an operating system." It's not meant to be insulting, but the impression we've gotten is that the Mac side is dominant. >Other than the lack of software, they've done >a fair job so far, but if people would stop flaming long enough to >point out problems than maybe it could be better. Uh, what flaming? I've seen people pointing out problems, but nothing that can really be considered a flame, unless it's what I'm replying to. >For example, allowing anyone who feels like it to change the system >time on a unix machine is incredibly stupid, I agree. So tell Next >to take it out or at least protect it from casual studipity. We did. Several other people did. One of them apparently had to deal with it one too many times, and, in his frustration, posted asking whether he was completely off-base in thinking it was a problem. He's not. >But as another example, allowing BuildDisk to run suid is not quite as >stupid, if your system is standalone on someone's desk. BuildDisk alone wouldn't be a real problem. It's the fact that I can make anyone else's machine boot off of my disk that is the problem. I walk into the lab, boot the machine off my disk, bring it up on the network, and read anyone's files that I care to. I don't know too many faculty who'd be pleased if we added this feature to an undergrad lab. >If you want to be able to initialize a disk, pop it in and do it. >Preventing people from building the disk they're currently booted off >of is more a concern. No, that's not a problem at all. If they screw up the current system disk, they can't *do* anything with it. They've made work for the administrators, but they haven't gained access to anyone's files. It's a problem I can live with, although I'd probably remove it if we ever installed NeXTs publicly. More to the point, why do people need to make bootable optical disks so easily? Just how many do you need? If the machine has a hard disk or netboot server, 0. For optical-only, 1. Data disks should be trivial (and they are), but I can't see any real call for a setuid BuildDisk. Justifications, anyone? >Next has consistently said that they want to hide the unix from people >as much as possible. Their machines come configured for standalone use, >with *absolutely nothing* restricted from the user who sets up the machine. I don't have a problem with this. In many respects I think it's a good idea. The problem comes when they change Unix into something else to make it easier to hide. >If this is how you leave the machine (and if you're not on a network, why >not?) then for the most part it is no easier or harder to trash than a Mac. Why not? Well, I guess it's my Unix blood, but data integrity has appeal for me. The default configuration under 0.9 lets *anyone* do anything. If I were to purchase a NeXT as a personal machine (which has crossed my mind), I would make the same changes to it that I make to the one in my office, if only because I like my files intact. >2) Even when on a network, Nexts are still set up to make network > configuration for a small homogeneous network as painless as possible. > I think this is as it should be if Joe Prof. is going to buy one. If a random professor buys NeXTs out of his research money, I agree that things should be simple. And it will work fine, as long as they speak only to each other. I have no problems with it at this point, and I'll be happy to help out. When they ask about connecting it to the rest of the department, they start to need that friendly Unix expert (cunningly disguised as campus support). When they ask about sharing files with non-NeXTs, they start to need their own Unix person. And so it goes. Eventually they get to sendmail... >Do you think he has >enough knowledge of unix to get the thing up and running in a massive >heterogeneous environment anyway? Not the Profs around here. Nor here, for the most part, but they don't need to. When they've had their machine running standalone for four months and suddenly want it on our network, *we* have to deal with how it integrates with the other machines we have. Pretty sysadmin tools don't help for that. We need to treat it as a Unix box. We need to handle routing (static routing is a typo under 0.9), sendmail (sendmail.cf and aliases were moved elsewhere without documenting the change), NFS (mount and umount don't work right once autodiskmount is started), accounts (NetInfo + YP + whatevercomesnext), and, most importantly, security (vaguely supported under 0.9). Not to mention finding out what they've customized. These are the things we (or at least I) pay attention to, and they're the ones that determine how we view the machine. No amount of design philosophy can hide the fact that someone, somewhere along the line, ends up dealing with it as a Unix machine. When it reaches that point, it's a good idea for it to be as normal as possible. That's why we didn't like the gratuitous filesystem reorganization in 0.8. >Gee, maybe that's why they wanted to have campus support people? Say it isn't so! :-) >3)There are two sets of people losing their heads consistently in this group. Three. >The first group can't wait to get their hands on sources so they can see >which calls Next used to write stuff, and then they'd probably complain >about the order of parameters or something of equal redeeming value. If this is what you think the source argument is about, you've successfully convinced me that we don't live in the same world. If you meant it to give me a case of the giggles, thanks. I needed it. >They said it wasn't going to happen unless you had a good reason, find one. <snicker> You're leading us on, right? >Maybe if some of the overunixed >people smashed their heads into those of the underunixed we could all get >some work done. "overunixed?" "underunixed?" Where the bloody heck are *you*? "justrightunixedandproudaspunchaboutit?" Sounds that way... >Another example: Using the same software techniques that Sun administraters >use to prevent access to the singleuser boot, we've had Nexts in PUBLIC labs >for people to try out since late December. Every once in a while someone >would have to go reboot one (a 0.8 trademark) but the security of the machine >or the network was never an issue. Very impressive. So what happens when I sit down, halt the machine, diddle kernel memory, and continue with a root shell? What happens when I insert my carefully-prepared optical disk and take over a machine? If you run off opticals, what stops me from taking the boot disk from one, modifying it in another, and putting it back? Do your software techniques involve shutting off autodiskmount, stripping setuid from everything in sight, hacking rc.boot, and other "Unix-knowledge-required" methods? This is what it would take to stop the casual intruder, and as for the determined hacker, forget it. I'm not attacking you here, in fact I'd love to hear what you've done, but my concern is how much *more* needs to be done to secure a NeXT than a "normal" workstation. >4)Need I remind you all that we're talking about a BETA machine here. People >seem to keep forgetting that the software release they're running has a major >version number of "0". I can't forget. The number of times I have to reboot (averaging at least once a day) serves as a constant reminder. >As I see it, the whole point of this massive and >unprecedented beta test was to help them make a "final product" that would >better meet the needs of their market than anything that exists so far. (side note: one could say much the same about Word 4.0 on a Mac, but one would be deluded. Not necessarily relevant, but who knows?) Well, the result is that we've determined that we're not part of the market, at least for now. NeXT currently doesn't fit into our environment. We're still following the machine, making suggestions and reporting problems, but we're not buying. I have great hopes for 1.0, but my realistic expectations are more modest. Maybe they can still blow us away with the real release, but some people have given up believing. >In the >mean time all of you eager beavers could be looking for things that might >potentially harm the system and informing CALMLY both Next and the rest of >us so that we can take steps to protect ourselves from disaster. So who's not being calm? I've been very careful to restrain myself from posting some of my more volatile commentary (which I quite cheerfully discuss in email or in person). I don't recall anything particularly vitriolic from others recently, so maybe you're overreacting just a tad? >I think I've stated my point emough here. You all have a chance to >make a difference, but instead you spend all day flaming Next for I suggest using the on-line Webster's to look up "hyperbole". Also "flame". These should be sufficient for you to categorize your statement. >Everything you say either >applies to others vendors as well, or is a complaint about an attempt >Next has made to solve problems that other vendors have as givens. Nope. Many of them are particular problems that NeXT has introduced by trying to marry Macs with workstations. Attempting to satisfy both ends isn't easy, and my impression is that they lean towards the Mac end when a conflict arises. I have problems with that, since I'm sitting squarely among the workstations. >I've been just as pissed at the machine as any of you on occassion, >but they've said they're going to fix things so I report 'em and put >up workarounds for the users here. Part of my problem is that I have two categories of things wrong with the NeXT: things that don't work the way they're supposed to, and things that don't work the way I think they should. I can expect bugs to be fixed when I report them, but what do I do about something that is a deliberate design feature, and that works just fine? I might dislike it so much that I won't buy the machine, but it's going to be a lot harder to get fixed. I consider the modification to /bin/su to be *evil*, and if I didn't have 4.3 source it would be a serious problem. It's a feature, and I despise it with a passion. Will it get "fixed"? Wish I knew. >Real tough to do. Save your flames for worthwile problems. If I ever flame NeXT, you'll know it. Trust me. The times I've been really tempted, I've refrained mostly because it *is* pre-release, and they're trying hard to finish it. Not to mention that it wouldn't accomplish anything besides telling the world that I'm unhappy. >These are MY opinions, >if you don't agree with them, >piss off. Nice touch, for someone who complains about flaming. I suggest you take your own advice in this. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
george@cornell.UUCP (George R. Boyce) (06/09/89)
NeXT, How about providing a shell script, "/etc/.i'm not a naive user.", which would turn off all the appropriate setuid bits, fix all the right file protections, turn on password protection to all the nasty things, etc. By the time a naive user found the file and figured out how to execute it, they would not be naive, right? This would allow the rest of your buyers an easy way of *finding* and "correcting" all the non-standard stuff that you have done to support the most naive of your customers. Just an idea... George, george@cs.cornell.edu P.s. hee hee... how about making it a binary with a built-in quiz and if you don't score high enough, you don't pass GO, you don't become a unix guru.
hobbes@caen.engin.umich.edu (Steven J Mattson) (06/09/89)
From article <51542@tut.cis.ohio-state.edu>, by jgreely@lisa.cis.ohio-state.edu (J Greely):
> [Lots of helpful info, punctuated with cigarette smoke.]
While I may have oversimplified some of the problems with the machine in my
last message, I think jgreely's response serves to prove my point. There's
been a lot of vapor vented in this group over things that could be just simply
stated and discussed. Jgreely did just that, and people who aren't system
administrators probably learned more about how to protect things in that one
message than previously ever in comp.sys.next. Go read it again. I agree
with him that we're probably not going to protect a lab machine completely
from the determined hacker but as long as people don't do anything foolish
like trust lab machines then big deal. If you're good enough you can do
anything you want to any machine you can get physical access to, period.
But still, the machine isn't supposed to be "Unix knowledge required" in a
standalone setting. While a good number of the people here are system
administrators and do know what's going on, Joe Prof. doesn't. As a support
person I'd rather have to only reconfigure those machines that Profs want
to the network than have to preconfigure everything into every machine and
explain to him what doesn't work the way his documentation says it should
for options he doesn't even want. If he wants our services, then it's our
job to make things as painless as possible for him so that he can get on
with his work.
-Steve Mattson
Computer Aided Engineering Network ANYONE can edit
University of Michigan a text file to
hobbes@caen.engin.umich.edu his own advantage.jgreely@lisa.cis.ohio-state.edu (J Greely) (06/09/89)
In article <5169@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >There are always going to be applications that seem to be overly privileged >as shipped --- this is necessary to handle that naive, standalone user. ...and, try as I might, I can't fault you for that. >I think it would be valuable; however, to get feedback on any area where >system administrators feel they can not protect their system. I will then >attempt to make sure that we can find solutions to get into 1.0. Now *there's* an offer we can't refuse :-). Should those of us submitting bug reports through the regular route just make lump "security suggestion" reports? While I'm on the subject, who is (are) the anonymous entity (entities) who handle initial responses to bug reports? I understand the desire to have all responses directed to the central mailbox, but when replying to a reply to a bug report I like to feel that I'm talking to a person. When I'm writing to someone who goes by the name of "NeXT Technical Services Bug Reporting", I feel like I'm yelling at a wall. I've thought about formally suggesting that the reply software be hacked to include the person's name, while leaving the address pointed at the group. Comments? >I also think it would be very valuable to put together a list of things >that a system administrator might want to do (e.g., disable setuid on >Preferences, remove BuildDisk, ...) and make it available to other system >administrators. Perhaps someone out there would like to be the collection >point for this. There's only one collection point that can really work, and that's NeXT. We can hunt for security problems all day, and never be sure that we haven't missed something that has been deliberately introduced to help the naive user. Eventually we'll find or hear about most problems, but it would be nice if we *knew* what had been changed to accommodate the hypothetical new user, and you're the only people who know all of the changes. Still, if people would like a clearinghouse for security problems and fixes under 0.9, I'll be happy to collect and redistribute them to interested parties. Someone out there has probably spotted something I missed, so I'm not being *entirely* altruistic. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
UH2@PSUVM.BITNET (Lee Sailer) (06/10/89)
I think maybe it would be a good idea for NeXT to deliver the box with some way to choose among two or more "configurations". One mode would be for people who intend to run almost always in a *single user* mode. I don't mean the Unix notion of single user, I mean the social notion---one person has the machine, runs it, is *responsible* for it, locks the door to keep strangers away from it, and knows what he or she is doing. Another mode is *end user* mode. This is still a single user mode, with the difference being that some expert elsewhere is responsible for administering the machine, changing the time, backing up disks, etc. A third mode is *shared user* mode, which will be common in trusted lab or office environments. Probably lots of users, but one administrator. A possible fourth *public mode* might be necessary for untrusted public labs, and I know that a lot of Comp Center folks are busily trying to figure out good ways to manage that type of environment. Good luck. My point is that rather than delivering *ONE* default mode, NeXT might deliver two or more, with an easy to use front end for switching between modes. The difference between modes might be things like o Which programs are suid. o Protections on sensitve files and directories. o Ulimits and umasks. o Permissions to change the time. o Default PATHs etc etc etc.
ali@polya.Stanford.EDU (Ali T. Ozer) (06/10/89)
In article <51575@tut.cis.ohio-state.edu> J Greely writes: > While I'm on the subject, who is (are) the anonymous entity >(entities) who handle initial responses to bug reports? I understand >the desire to have all responses directed to the central mailbox, but >when replying to a reply to a bug report I like to feel that I'm >talking to a person. When I'm writing to someone who goes by the name >of "NeXT Technical Services Bug Reporting", I feel like I'm yelling at >a wall. I've thought about formally suggesting that the reply >software be hacked to include the person's name, while leaving the >address pointed at the group. Comments? Please be assured that there are real human entities behind that alias. 8-) I've forwarded your suggestion to the group. Ali Ozer, NeXT Developer Support aozer@NeXT.com
avie@wb1.cs.cmu.edu (Avadis Tevanian) (06/10/89)
In article <51575@tut.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >Now *there's* an offer we can't refuse :-). Should those of us >submitting bug reports through the regular route just make lump >"security suggestion" reports? > I would suggest that you make "security suggestions" through the normal route. In addition, feel free to send me copies of those suggestions at avie@next.com. I am especially interested in areas where you feel you may not be able to correct something you feel that we have done wrong. -- Avadis Tevanian, Jr. (Avie) Manager, System Software Group / Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
mcdonald@uxe.cso.uiuc.edu (06/11/89)
>My point is that rather than delivering *ONE* default mode, NeXT might >deliver two or more, with an easy to use front end for switching between >modes. The difference between modes might be things like > o Which programs are suid. > o Protections on sensitve files and directories. > o Ulimits and umasks. > o Permissions to change the time. > o Default PATHs Unix is a big, complicated system. NeXt should send along a big, complicated book with each machine which explains how it works, all the things which have been mentioned in this thread in comp.sys.next, and a LONG, VERY DETAILED description of excatly what differences exist AND WHY between the various "modes" od setup described above. Having both the different modes and a good book to explain them would be one of the most brilliant ploys ever in computerdom. Trying to pretend that a complicated system is simple is folly. It is OK to try only if the machine is used only for one task and unconnected to the rest of the world. Doug McDonald .