mparker@chip.UUCP (M. D. Parker) (07/27/88)
I have noticed the tendency for some programs in UNIX to have hard links.
The program operation is then determined by the name it was invoked by.
As a system administrator this makes it very difficult for me to restrict
one program without restricting all their linked set. And the problems
is not just simply removing the hard link, since experimentations have
proved that symbolic links do the same. Thereby preventing restriction
again.
I'd like to request that in future releases, this short-cut be eliminated.
===============================================================================
M. D. Parker ARPANet: chip!mparker@nosc.mil
UNIX Systems Manager UUCP: ...{ucsd,nosc,hp-sdd,crash}!chip!mparker
Phone: (619) 457-2340
USPS: M/A-COM Government Systems, 3033 Science Park Road, San Diego, CA 92121
Disclaimer: Opinions expressed are my own and not necessarily that of
M/A-COM Government Systems Inc.pdb@sei.cmu.edu (Patrick Barron) (07/27/88)
You can get exactly the effect you want by just eliminating the links and making discrete copies of the program under the different names. You can then protect the individual copies as you wish. --Pat.
cosell@bbn.com (Bernie Cosell) (07/27/88)
In article <2950@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: } }You can get exactly the effect you want by just eliminating the links }and making discrete copies of the program under the different names. }You can then protect the individual copies as you wish. I thought of this, too, but it doesn't work. The posting wasn't clear about what he wanted "restricted" to mean, but consider something like this: imagine that telnet was set up to use this link hack: if you start it with some host-name, it'll just connect you to that host. So you now have: telnet ln telnet myhost1 ln telnet myhost2 ln telnet myhost3 ... Now, imagine that you are under "orders" to limit access to, say, the arpanet. Thus, no more allowing folk to "free form" 'telnet your.host.edu'. Well, you can rm telnet, and in fact ONLY leave around the "myhostN"s that correspond to the hosts you are willing to allow the users to access (this is the moral equivalent of what you suggested, but actually rm'ing the restricted versions instead of just unlinking them). Now what? Well, the first enterprising user to figure out that ln -s /wherever/myhost1 telnet in his home directory will REENABLE the telnet access you so carefully tried to turn off. If the user has a directory on the right filesystem, he can even use a hard link, or copy the executable to a new name or whatever. Altogether, it is not easy to fix. __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
karish@denali.stanford.edu (Chuck Karish) (07/27/88)
In article <184@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >I have noticed the tendency for some programs in UNIX to have hard links. >The program operation is then determined by the name it was invoked by. >As a system administrator this makes it very difficult for me to restrict >one program without restricting all their linked set. Why don't you just remove one of the links, and make a second copy of the program? The remaining administrative problem is keeping track of which programs need to be copied this way when a new version of the operating system is installed. The installation log files (``tar v'' output) tell you when links are made, as opposed to actual file extractions. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
eggert@sm.unisys.com (Paul Eggert) (07/27/88)
In article <184@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes:
I have noticed the tendency for some programs in UNIX to have hard
links.... this makes it very difficult for me to restrict one program
without restricting all their linked set.... I'd like to request that
in future releases, this short-cut be eliminated.
This short cut saves disk space and cuts down on paging/swapping, so a blanket
request like this will probably be ignored unless you give more details.
Surely you don't want to let some people run 'compress' and others 'uncompress'!
Are you complaining about chfn/chsh/passwd by any chance?les@chinet.chi.il.us (Leslie Mikesell) (07/27/88)
In article <184@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >I have noticed the tendency for some programs in UNIX to have hard links. >The program operation is then determined by the name it was invoked by. >As a system administrator this makes it very difficult for me to restrict >one program without restricting all their linked set. And the problems >is not just simply removing the hard link, since experimentations have >proved that symbolic links do the same. Thereby preventing restriction >again. The file permissions are stored in the inodes, and to get another inode you have to duplicate the data... Starting with link-a and link-b as two different links to the same file: rm link-b cp link-a link-b Now the files are no longer linked and you can chown/chmod independently. Unfortunately, you also use extra disk space for each copy and do not gain the advantage of shared-text when multiple copies are running when invoked by the different names. Les Mikesell
chris@mimsy.UUCP (Chris Torek) (07/27/88)
It is not broken; please do not `fix' it. If the goal is to prevent programs from running with arbitrary arguments (including argv[0]), then do that (via the available protection mechanisms, such as groups). For instance, if students should not be allowed remote access to arbitrary hosts: % ls -lg /usr/ucb/rsh /usr/ucb/rlogin -rwsr-x--- 1 root ins 30720 Mar 15 11:31 /usr/ucb/rlogin -rwsr-x--- 1 root ins 28672 Sep 2 1987 /usr/ucb/rsh % ls -lg local_host -rwxr-sr-x 1 bin ins <size> <date, time> local_host % ls -l local_host remote_host lrwxrwxrwx 1 bin 12 Jun 11 04:13 remote_host -> /usr/ucb/rsh where `local_host' is a link to a program that makes sure the arguments are to be allowed to students, then runs /usr/ucb/rsh, and where `ins' is a group that excludes students. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mparker@chip.UUCP (M. D. Parker) (07/27/88)
In article <184@chip.UUCP>, mparker@chip.UUCP (M. D. Parker) writes: > I have noticed the tendency for some programs in UNIX to have hard links. > The program operation is then determined by the name it was invoked by. > As a system administrator this makes it very difficult for me to restrict > one program without restricting all their linked set. And the problems > is not just simply removing the hard link, since experimentations have > proved that symbolic links do the same. Thereby preventing restriction > again. > > I'd like to request that in future releases, this short-cut be eliminated. > Seems from the messages, I have generated a bit of confusion. Therefore, perhaps a simple example taken from real life. I want to prevent users from examining the mailq using the /usr/ucb/mailq program because I feel that who a user sends mail to should not be subject to disclosure to others. Problem seems simple, perform a chmod on /usr/ucb/mailq and all is well. Complication comes because /usr/ucb/mailq and /usr/lib/sendmail are HARD LINKED together. CHMODing one does the same for the other. First try. Make another copy of /usr/ucb/sendmail and call it /usr/ucb/mailq. Programs no longer have HARD LINKs and can be protected individually. Complication here, if a user creates a SYMBOLIC LINK to the program as: ln -s /usr/lib/sendmail mailq and then executes the program 'mailq', the effect is identical to running /usr/ucb/mailq prior to my making the copy. In otherwords, since the program is scanning the argument list for its name it was invoked by, my protection is VERY limited. I am therefore unable to do what I originally want, i.e. to restrict the mailq program. For the above reason, deletion and removal of the HARD LINK will not work. My only fix, if I had sources, would be to compile seperate versions of these linked programs so that the argument list check would be inhibited. However, without source it is nearly impossible to correct. Therefore, the easiest way to fix this is if people on the development side would not rely on this technique. Hmm...be an interesting way to get a privledged trojan horse into the system wouldn't it by hiding it into an install. Think about this one the next time you install code obtained from the outside. =============================================================================== M. D. Parker ARPANet: chip!mparker@nosc.mil UNIX Systems Manager UUCP: ...{ucsd,nosc,hp-sdd,crash}!chip!mparker Phone: (619) 457-2340 USPS: M/A-COM Government Systems, 3033 Science Park Road, San Diego, CA 92121 Disclaimer: Opinions expressed are my own and not necessarily that of M/A-COM Government Systems Inc.
ok@quintus.uucp (Richard A. O'Keefe) (07/27/88)
In article <27498@bbn.COM> cosell@bbn.com (Bernie Cosell) writes: >In article <2950@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: >}You can get exactly the effect you want by just eliminating the links >}and making discrete copies of the program under the different names. >}You can then protect the individual copies as you wish. > I thought of this, too, but it doesn't work. ... > Well, the first enterprising user to figure out that > ln -s /wherever/myhost1 telnet > in his home directory will REENABLE the telnet access you so carefully tried > to turn off. If the user has a directory on the right filesystem, he can > even use a hard link, or copy the executable to a new name or whatever. > > Altogether, it is not easy to fix. Since a program can supply any string it likes in argv[0], even forbidding every sort of link altogether wouln't permit the original poster to do what he apparently wants. To continue with the telnet example: main(argc, argv, envv) int argc; char **argv; char **envv; { char *realprog = "/wherever/myhost"; argv[0] = "telnet"; execve(realprog, argv, envv); perror(realprog); exit(1); } The problem isn't links: it's programs which decide what to do based on their name. But the name is just another argument. The problem, then, is that if there is one program which can do several operations, depending on an argument to determine which, you can't give a user permission to do some of the operations without giving him permission to do all of them. This is a surprise? It might be possible to put the program in a special group, which none of the restricted users belongs to, and write a set of set-group-id shell scripts to call the program appropriately. Then restricted users couldn't get at the program directly, and couldn't fake it through the scripts.
wisner@killer.DALLAS.TX.US (Bill "Spam Eggs Sausage and Spam" Wisner) (07/27/88)
Bad example. Even if you completely wipe out the ability to run sendmail
as "mailq," you can still run it as "sendmail -bp".
And links, hard or soft, aren't the only way. How's this:
main()
{
execl("/usr/lib/sendmail","mailq",0);
}
--
Bill Wisner / wisner@killer.dallas.tx.us / +1 208 286 7929df@nud.UUCP (Dale Farnsworth) (07/27/88)
M. D. Parker (mparker@chip.UUCP) writes: > I have noticed the tendency for some programs in UNIX to have hard links. > The program operation is then determined by the name it was invoked by. > > I'd like to request that in future releases, this short-cut be eliminated. Argv[0] is just like any other argument to a unix program. If a program shouldn't change its behavior based on argv[0], it shouldn't change its behavior on argv[1], argv[2], .... Programs that provide more features than are absolutely necessary for the job at hand are necessarily less secure than a program without the additional features. Security comes at a price. -Dale -- Dale Farnsworth 602-438-3092 noao!nud!df
les@chinet.chi.il.us (Leslie Mikesell) (07/28/88)
In article <185@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >Programs no longer have HARD LINKs and can be protected individually. >Complication here, if a user creates a SYMBOLIC LINK to the program as: > > ln -s /usr/lib/sendmail mailq > >and then executes the program 'mailq', the effect is identical to running >/usr/ucb/mailq prior to my making the copy. But most programs have command line switches that override the program name, and it is easy enough to pass a fake argv[0] to a program anyway. To control things to the extent that you want, you either have to write all the programs yourself or make the programs executable only by a certain user or group ID. Then you can write a front-end program that is set[ug]id that knows who is allowed to execute which programs with which arguments. Several such programs have been posted to the net to allow some users access to root without knowing the root password, but they should work as well (and be safer) with some other special ID set up for that purpose. Les Mikesell
steve@altos86.UUCP (Steve Scherf) (07/29/88)
In article <184@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >I have noticed the tendency for some programs in UNIX to have hard links. >The program operation is then determined by the name it was invoked by. ... >I'd like to request that in future releases, this short-cut be eliminated. It's not exactly a short-cut. It saves disk space, and this can be crucial sometimes. Steve Scherf ...!ucbvax!sun!altos86 ...!ucbvax!ucscc!ssyx!barsoom barsoom@ssyx.ucsc.edu ----- Don't blame Altos for any stupidity printed above.
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/29/88)
Actually, you can disable mailq on a binary site. After moving the
original /usr/lib/sendmail to a protected copy somewhere, crank up
emacs on the "public" binary. Find the argv[0] comparison table
(just search for "mailq") and replace the m with a null.
You also have to find the check for -bq and nuke it as well...
--
VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CAmaart@cs.vu.nl (Maarten Litmaath) (07/30/88)
In article <10358@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes:
\Actually, you can disable mailq on a binary site. After moving the
\original /usr/lib/sendmail to a protected copy somewhere, crank up
\emacs on the "public" binary. Find the argv[0] comparison table
\(just search for "mailq") and replace the m with a null.
What if I invoked the program with argv[0] ""?
--
If you enjoyed the recent heat wave, |Maarten Litmaath @ Free U Amsterdam:
you'll certainly like the ozone gap...|maart@cs.vu.nl, mcvax!botter!maarthoffman@pitt.UUCP (Bob Hoffman) (07/30/88)
In article <185@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >... I want to prevent users from >examining the mailq using the /usr/ucb/mailq program I believe it can be done by setting protections and group-IDs carefully. First of all, I think it's safe to assume that you don't want any of your users executing /usr/lib/sendmail directly for any reason. Sendmail is normally invoked by the users' mail agent, e.g. /bin/mail, /usr/ucb/Mail, etc. I propose a way of restricting execution of /usr/lib/sendmail without losing any functionality for the users sending or receiving mail or for the administration of the mail facility. 1. Create a group in /etc/group called 'mail' that includes the system manager. mail::7:root 2. Change the group ID and protection on /usr/lib/sendmail (and its links, newaliases and mailq) so that only group 'mail' can execute it: -rwsr-x--- 2 root mail 112640 Mar 27 15:33 /usr/lib/sendmail 3. Change the group ID and set-GID bits on each mail user agent and any other program that might have need to call sendmail: -rwsr-sr-x 1 root mail 41984 Dec 30 1987 /bin/mail -rwxr-sr-x 1 root mail 14336 Jun 6 1986 /bin/rmail -rwxr-sr-x 1 root mail 185344 Jun 7 13:08 /usr/local/bin/elm -rwxr-sr-x 2 root mail 74752 Dec 31 1987 /usr/ucb/Mail 4. Finally, make sure /usr/spool/mqueue is not world-readable: drwxrwx--- 2 root mail 2048 Jul 29 14:50 /usr/spool/mqueue/ I believe this will do as Mr. Parker asks. Have I overlooked anything? -- Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman Pitt Computer Science hoffman@vax.cs.pittsburgh.edu
jcs@tarkus.UUCP (John C. Sucilla) (07/30/88)
In article <185@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >First try. Make another copy of /usr/ucb/sendmail and call it /usr/ucb/mailq. >Programs no longer have HARD LINKs and can be protected individually. >Complication here, if a user creates a SYMBOLIC LINK to the program as: > ln -s /usr/lib/sendmail mailq How about changing the mode to rwx--x--x (711) so they can't copy it or create new links but can still execute it? Or do these "symbolic links" let you get around permissions? I don't know, I know 0 about symbolic links but I've got a sneaking suspicion it's part of BSD UNIX. -- John "C". Sucilla, A silicon based life form. {att,chinet,ddsw1}!tarkus!jcs You have a better idea? Now's the time..
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/31/88)
In article <1339@ark.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >In article <10358@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: >\Actually, you can disable mailq on a binary site. After moving the >\original /usr/lib/sendmail to a protected copy somewhere, crank up >\emacs on the "public" binary. Find the argv[0] comparison table >\(just search for "mailq") and replace the m with a null. > >What if I invoked the program with argv[0] ""? It defaults to "sendmail" mode. -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
mike@turing.unm.edu (Michael I. Bushnell) (08/03/88)
In article <3642@pitt.UUCP> hoffman@vax.cs.pittsburgh.edu (Bob Hoffman) writes: >In article <185@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >>... I want to prevent users from >>examining the mailq using the /usr/ucb/mailq program >I believe it can be done by setting protections and group-IDs >carefully. First of all, I think it's safe to assume that you >don't want any of your users executing /usr/lib/sendmail directly >for any reason. Sendmail is normally invoked by the users' mail >agent, e.g. /bin/mail, /usr/ucb/Mail, etc. I propose a way of >restricting execution of /usr/lib/sendmail without losing any >functionality for the users sending or receiving mail or for the >administration of the mail facility. Oh, please, please don't inflict pain on your users like this. What if I want to write my own mail agent? Say I like emacs? Then I get emacs's mail agent, which calls sendmail. Sendmail is intended to usable by arbitrary bozos, who will usually want to use a nice interface instead. Also, you can get some access to sendmail with "telnet localhost smtp", anyway. -- N u m q u a m G l o r i a D e o Michael I. Bushnell HASA - "A" division mike@turing.unm.edu {ucbvax,gatech}!unmvax!turing.unm.edu!mike
jbayer@ispi.UUCP (id for use with uunet/usenet) (08/03/88)
Another workable solution is to do the following steps: 1. Move the programs you want to restrict to a directory readable only by the super user. 2. Create a shell script for each type of call for each program 3. Make the shell script executable by everyone. 4. Make the owner of the shell script the super user 5. Set the user bit for the shell script (chmod u+s name) Now no matter how someone calls the shell script the program will still be called using the correct name. Jonathan Bayer Intelligent Software Products, inc. 19 Virginia Ave. Rockville Centre, NY 11570 uunet!ispi!jbayer
chris@mimsy.UUCP (Chris Torek) (08/04/88)
In article <153@ispi.UUCP> jbayer@ispi.UUCP writes: >Another workable solution is ... [to:] >Create a shell script .... >Make the shell script executable by everyone. >Make the owner of the shell script the super user >Set the user bit for the shell script (chmod u+s name) Setuid scripts are not available in vanilla System V. Setuid shell scripts are a security hole in vanilla BSD. If you have not either made extensive kernel changes, or else installed the fix from Berkeley that simply disables set-ID scripts, and you make a setuid shell script (for either sh or csh), I can become that user on your machine given access to any ordinary user account. I am not willing to publish the method here; I will say that disabling setuid scripts in the kernel, or simply not creating them in the first place, suffices to prevent this avenue of attack. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
egs@killer.DALLAS.TX.US (Eric Schnoebelen) (08/04/88)
In article <153@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: > >Another workable solution is to do the following steps: > > 1. Move the programs you want to restrict to a directory > readable only by the super user. > 2. Create a shell script for each type of call for each program > 3. Make the shell script executable by everyone. > 4. Make the owner of the shell script the super user > 5. Set the user bit for the shell script (chmod u+s name) Over in comp.unix.wizards they are having a nice little discussion about setuid shell scripts, and several people have shown how they are a larger security hole than the programs being discussed here. ( see comp.unix.wizards for examples ) A better choice for this solution might be to write small 'wrapper' programs, and set the suid bit on them. >Now no matter how someone calls the shell script the program will still >be called using the correct name. > >Jonathan Bayer >Intelligent Software Products, inc. >19 Virginia Ave. >Rockville Centre, NY 11570 >uunet!ispi!jbayer Eric Schnoebelen John W. Bridges & Associates, Inc. Lewisville, Tx. 75067 u-word!egs@killer.dallas.tx.us
willy@philapd.UUCP (Willy Konijnenberg) (08/07/88)
In article <153@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: > >Another workable solution is to do the following steps: > 4. Make the owner of the shell script the super user > 5. Set the user bit for the shell script (chmod u+s name) This works only if you have a shell that acknowledges the suid bit! The Korn shell does that ONLY IF explicitly installed to do so, the standard SV Bourne shell does NOT. I don't know about the C-shell or any other shells. If your shell does not handle the suid bit, you will have to write a small front end in C to call the shell script. This front end merely does an execvp of the shell script with it's argv. BTW, You could have the shell script check it's arg0 to determine the action to be taken, and use links to make all "sensitive" commands end up in this single shell script. (Weren't links the original problem? :-) -- Willy Konijnenberg <willy@idca.tds.philips.nl> Philips Telecommunication & Data Systems, Department SSP/V2. Apeldoorn, The Netherlands.