gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/13/87)
In article <172@herman.UUCP> det@herman.UUCP (Derek Terveer) writes: >... My gripe happens to be security. I find >the user/group/world security quite cumbersome and tedious to manage as a >system administrator with a brood of ~70 users. To me, a security scheme >should be a tad more specific than Unix allows. It isn't all that hard to implement an Access Control List scheme for UNIX; the main difficulty lies in integrating it into the existing system. I plan to produce a simple ACL system sometime this year (it's needed as part of a large application project) and will make it available free to whoever wants it. Most likely its use won't be transparent (e.g., one might have to invoke a utility to provide the access, rather than having it done by the shell or other normal part of UNIX).
bannon@betelgeuse.csc.ti.com (Tom Bannon) (08/25/90)
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
tchrist@convex.COM (Tom Christiansen) (08/28/90)
I've received a lot of mail from people who didn't understand my (or Peter's, it would seem) postings about readable binaries. Permit me to elucidate. The reason that you shouldn't try to protect yourself by making system binaries unreadable is that you're not relying on password interrogation or even setuid programs, but on pure, unreliable ignorance. Once the secret is out, it can't be taken back. Never rely on someone not knowing how to something to keep them from doing it. Someday you'll be sorry. BTW, on these fascist systems with system binaries that aren't readable, what happens when these binaries take a SIGQUIT or some other coredump signal? Do you get a core dump with text you can read? On most UNIX systems I know, you do, which blows your wonderful security out of the water. Of what about attaching to running processes, such as with gdb? It's your process, so you can attach to it, right? Then you can read its text! There are lots of other ways. Getting a hold of backup tapes or root core dumps or all kinds of things will give away your shop if you rely upon this method. As to "who adb's system binaries," the answer is me and anyone else who wants to track down what's broken when something breaks. I don't always have root on the machine, but I still try to figure out what happened. Not being able to get at the binary is a serious impediment to this. --tom -- "UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things." [Doug Gwyn]