pete@wvus.wciu.edu (Pete Gregory) (11/30/90)
Is there any good reason why UNIX systems are shipped with the read bit set
for 'other' in /bin and /usr/bin binaries?
We'd like to turn the read bits off for all but user and group.
I'm aware that shell scripts are exempt from this possibility (right?),
because sh needs to be able to read the file.
Ignorant minds want to know...
Pete Gregory, UNIX SA | pete@wvus.wciu.edu |
World Vision USA/ISD | wciu!wvus!pete ___|___
919 W. Huntingon Dr. | Voice: 818/357-7979 x3347 |
Monrovia, CA 91016 | FAX: 818/303-6212 |
|aglew@crhc.uiuc.edu (Andy Glew) (12/10/90)
>Is there any good reason why UNIX systems are shipped with the read bit set >for 'other' in /bin and /usr/bin binaries? Are you trying to promote "security" by doing this? I am not adverse to security (having worked at the company that put out the first NCSA certified secure UNIX), but I believe that such "security through obscurity" approaches are foolish. On the other hand, a reason for letting the world read binaries: I frequently am asked to help people use UNIX tools - sometimes the old standards, sometimes third party commercial software. Frequently the user is being frustrated by error messages of the form "File not found". Usually my first step is to run strings on the binary, to find out what files it is looking for. Is this a good reason? Not if you've got a bullet-proof product. But I doubt that you do. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
tchrist@convex.COM (Tom Christiansen) (12/10/90)
In article <ug1eT2w163w@wvus.wciu.edu> pete@wvus.wciu.edu (Pete Gregory) writes: >Is there any good reason why UNIX systems are shipped with the read bit set >for 'other' in /bin and /usr/bin binaries? > >We'd like to turn the read bits off for all but user and group. This comes up often. Why bother? There's no possible harm from letting people read binaries, and if there is, you've done something wrong. Also, you can almost certainly get a core dump of these, which will yield the code anyway. I only know one system where this is fixed. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
israel.pad@nixdorf.com (Andreas Israel) (12/11/90)
In <AGLEW.90Dec9221950@basagran.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: >>Is there any good reason why UNIX systems are shipped with the read bit set >>for 'other' in /bin and /usr/bin binaries? >On the other hand, a reason for letting the world read binaries: I >frequently am asked to help people use UNIX tools - sometimes the old >[...] >found". Usually my first step is to run strings on the binary, to >find out what files it is looking for. > Is this a good reason? Not if you've got a bullet-proof product. Last week I had a similar problem. I was asked to help solving a problem (a debugger failed to execle the debugged program). The problem was the following: The debugger (GNU's gdb) calls the program via "execle("/bin/sh", "sh", "-c", cmd, 0, envp)". And our system will not do the exec after a ptrace call, if the user has no read access to the called program (in this case /bin/sh). There may be some security problems with set-UID programs, if these programs are not carefully programmed. But these problems remain even without read access. It's only harder to find it out. The solution is not to deny read access.