Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!cs.utexas.edu!csc.ti.com!ti-csl!m2.csc.ti.com!m2!bannon From: bannon@betelgeuse.csc.ti.com (Tom Bannon) Newsgroups: comp.unix.questions Subject: Security (was Re SUMMARY: C Compiler Predefined Manifest Definitions) Message-ID: Date: 24 Aug 90 20:03:58 GMT Sender: usenet@csc.ti.com (USENET News System) Organization: TI Computer Science Center, Dallas Lines: 39 In-Reply-To: tchrist@convex.COM's message of 23 Aug 90 15:27:23 GMT In article <105269@convex.convex.com> tchrist@convex.COM (Tom Christiansen) > In article <595@wattres.UUCP> steve@wattres.UUCP (Steve Watt) writes: > |Which brings up what I consider to be a strange point: Why is it that most > |*NIX vendors ship systems with all the files in /bin and /usr/bin world- > |readable? It seems to me that they only need to be world-executable... > Absurd. If you are relying about people not knowing about something > for your security, than you've really no security at all. > But the point of it's being annoying secondary to the fact that it > just doesn't make sense to rely upon ignorance to protect you. > Security through obscurity isn't. As well as From: peter@ficc.ferranti.com (Peter da Silva) > Security through obscurity is no security at all. Hmmm... I guess encryption is out then, being as it relies on the ignorance of the key. Ignorance, the absence of knowledge, seems to play a fundamental role in security. Even in Zero-knowledge proofs if I understand them correctly. You both seem to hold a different viewpoint however. Could you elaborate? tchrist@convex.COM (Tom Christiansen): > An unreadable binary is just annoying. You can't run what or strings > on it. You can't adb it for your core dumps. A good point. Perhaps this points out a problem with what, strings, and adb, i.e., the inability to read binaries that have restricted read permission. Whether there is a good general solution (setuid??) for this problem under Unix I don't know however. I would certainly like to hear about any if there were. Tom bannon@csc.ti.com