Right. Some of this was not a problem with demand-paged files (4.xBSD) since you would not share swap images. But there's more, or rather, *was* more, once people added PT_ATTACH and new system calls or behavior ... specifically, the setreuid / setregid calls from 4.2BSD or the saved setuid behavior in System V. This is one I personally touched. Suppose a process starts out setuid or setgid. This means it has alternative privileges (maybe super-user, maybe not). With these it can do things like open some files or transit some directories. Afterward, using setreuid() and setregid() in 4.2BSD, the process can swap its real and effective IDs, or give up its effective UID or GID entirely, to give up its privileges. So some program could, for instance, chdir past a "lock" directory -- this was the MDQS trick -- and now exist in a tree that it had no access to, or open a file with secrets, that it no longer has permission to open. Once a process had given up any special privileges, though, it could be ptraced again (via PT_ATTACH). Now you can swap file descriptor variables around in it, or otherwise make it do bad things with the privileges it gained while it was setuid. On SysV, with "saved setuid", it is even worse: you can make the process *regain* privileges and do whatever you want. The fix we used was an extra bit in the process flags: "process has had or used privileges". Once set (cleared only on exec()), the process could no longer be ptraced except by root. Processes did -- and still do -- have to be careful about files they may leave open, or other entities that survive exec(). (One should also consider mmap() and shared regions.) Chris

On Sat, May 13, 2017 at 11:25 AM, Steve Simon <steve(a)quintile.net> wrote: ​Speaking for myself..... I clearly don't think it is bad manners​ as this stage - I brought it up!E It was a different time when that occurred. Today, I think *the general security community*** pretty lives by the rules of if you find something, notify the folks that fix it as quickly as possible and try to get a patch out and figure out how to get that patch out. Then make damned sure the whole is well documented and published so: a) do we can test for it in the wild, b) make sure it does not happen again. It actually has always impressed me at how good UNIX was (is) when you really get down to it. IMHO, was less the 'thousand eyeballs'' and more the 'eye balls that all of cared, could do something about it and most importantly actually understood' the 'calculus' of the different problems were want made UNIX secure and as good if not better than many 'commercial' systems than its contemporaries. *i.e.* the UNIX schemes used sensible human based security processes/mechanisms combined with basic math & physics ( technology if you will) - as the higher order bits, not being secret or obscure to protect. Were there mistakes, yup. But frankly, VMS had as many if not more and some of them were far, far worse. IBM's OS were considered good, but their were documented exploits in the news there too. Clem ** I note 'security community' because not all firm buy into this behavior. I speak for myself. In the last few weeks my own employer (Intel) recent has been mixed up in a bit over played issue with server chips sets, AMT and Winders [its not my area/group etc but as I under the issue, the bug does not seem to effect UNIX flavors nor systems that do not use AMT - which is a server thingy]. Some outside of Intel people are have complained that folks that own the bug @ my employer has been less that forth coming. I'll not defend nor comment because it's not mine to comment on, other than to state I personally take an attitude of trying to say a much as I can and when I am in a position for my job I will and do.

On Sat, May 13, 2017 at 01:19:42PM -0400, William Pechter wrote: Those default account combinations were still being used to gain access to VMS systems in the '87-'89 time frame; although user/password was less interesting by itself, being an unpriviledged account. DF

On 14 May 2017 at 18:12, Dave Horsfall <dave(a)horsfall.org> wrote: I worked in a VAX shop once where a DEC FSE came by (on the wrong day with the sysadmin out) and was rather upset that the default account passwords had been changed. N.

Our biggest UNIX vs. DEC OS problem was that UNIX set the system clock in GMT whereas the DEC OSes of the day used local time. We got used to the time being 4/5 hours off after a DEC CE was there. We actually contracted our maintenance out for the entire company. We ended up going with GE. We couldn’t convince the guys from DEC who bid that when we said there were certain critical components of the site that needed 24-hour response, that this meant, 24 hours in a row, not three successive 8 hour days. We often were stuck using a DEC CE for initial system setup or warranty work. We had a particularly bad one who would blow power supplies, screw up running systems, etc. She was just simply incompetent. The culmination of this was when she managed somehow to put herself across the AC line of a VAX over in one of our external buildings and ended up being taken a way in an ambulance. Working off hours, we’d often set up the new machines and run diagnostic checks on them ahead of the CE showing up. I got a testy CE show up and tell me that he “didn’t need me checking up on his work.” (Hell, was the COTR and customer). I told him I only had one word to say about that <insert the incompetent CE’s name>. He beat a quick retreat saying that Nancy was a different story. I was driving to work one morning at Christmas time, and one of our local radio stations was soliciting people to send in their sob stories about how bad a year they had and they would be given a special gift. One story went on for a few minutes, and I hadn’t caught on until it got to the electrical shock at work part and I knew it was Nancy’s story. Our standard joke was that the way you could tell a DEC CE with a flat tire was that he had to change all four before he found the problem. Amusingly, working for the feds had some other interesting fiascos. I got an amusing message from the security and facilities people one day. I had to tell our CE. ME: Bill, I can’t let you in the machine room anymore. BILL: Why not ME: You’re a fire hazard. BILL: How so? ME: You have soldering irons. Of course, I was able to prevail on them that we’d keep an eye on the CE and stand by with fire suppression if we let him do his job. The machine room in my building had no automatic halon system which was popular in those days. What we had was a lot of large halon hand extinguishers. The post fire department came out and set pan fires behind our building and let us practice putting them out with the halon. I can’t imagine what the costs to the federal budget and the ozone layer were on that little activity. Of course, I brought my turnout gear as I was a firefighter and paramedic at the time. This led to another interesting call from the front office. SEC: You need to attend a CPR class. ME: I’ve already had one this year. I’m a state certified paramedic. I go through recurrent training every month. SEC: Well it is a requirement that you have a CPR card. ME: Why am I the only one in my office that this is a requirement for? SEC: It’s your job classification. ME: Because I’m an electrical engineer and the other guys are computer scientists? SEC: Yes. ME: Why? SEC: Because you work with electricity. ME: I work with digital logic. Five volts. Further, even if I was going to shock myself into cardiac arrest, I can’t do CPR on myself. You should make everybody else take CPR.

The wirewrap comment reminds me of another catastrophe. BRL had one of the few operational Denelcor HEP supercomputers. Amusingly the thing was front ended with an 11/34 and had an io processor with 32 Unibuses connected to it. While we were still shaking the thing out at the factory (Mike Muuss shot his mouth off that we could get UNIX to run on the thing, and it turned out nobody had a better idea). We'd come in at night (while the Denelcor employees had the machine in the day). I'd regularly read the log about what happened that day. Well, one day it read that someone had neatened up one of the system backplanes by taking the wires that were overly long and shortening them. Now this thing was all built out of 10800 ECL and those wires were "overly long" and stuffed into the backplane because the length was needed to control the signal propagation times. I told Mike I had a bad feeling about this and the machine might not be usable.