Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: comp.misc Subject: Re: Trojan Horse a Myth? Message-ID: <30800002@ccvaxa> Date: 9 Dec 87 06:37:00 GMT References: <459@gtx.com> Lines: 48 Nf-ID: #R:gtx.com:459:ccvaxa:30800002:000:2585 Nf-From: ccvaxa.UUCP!aglew Dec 9 00:37:00 1987 Break-ins to Gould's Secure UNIX: I'm not on Secure UNIX, but I believe that this is the real story - at a trade show, the Gould exhibit made the break-in challenge. Normally, of course, Secure UNIX administrators do not have . in their path, but in this case root had just finished installing a 3rd party software package that came complete with instructions to "Put . in your path in order to run the installation script". Sigh. The penetrator went up to the exhibitor, and asked him to help him out... try ls'ing this directory... Sigh. Now, the rules of the challenge expressly forbid Trojan Horses (since there's not too much the OS can do about stupid system administrators), but the penetrator got shirty, and the Gould exhibitor was probably nervous, so they made a ruckus about it. Eventually it got back here (we heard about it on the USEnet) and the penetrator got his prize. --- Enough of the company product. A 100% personal, definitely not company policy, widely disapproved of by my co-workers, opinion: the problem is not "." in the path. "." in the path is a great convenience. It lets you move around to particular environments, and use commands special to that environment. In fact, I have occasionally had a path that runs . ./bin ../bin ../../bin ../../../bin and so on - and it was *greatly* convenient. I would like to have a shell that had a syntax {../}*bin, or similar - search up the path until you get to the top. The trouble is not the relative pathnames - the trouble is that they relative pathnames are not *SECURE*. I mean, if /usr/bin is writable to the world, then not having . in his path doesn't help root at all. Nor (a more likely occurrence) does it help if root is installing a software package, picks up some filespace in /tmp, and starts running a long lasting installation procedure that uses scripts pulled from where he's installing. What is needed is a security predicate that prevents root from executing non-secure code *wherever* it might be found. This might involve, on every invocation, checking that the path to the / is non-writable, and so on. If you have such predicates, then relative pathnames like . and ./bin are as secure as any other. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.