leo@philmds.UUCP (Leo de Wit) (12/25/88)
In article <14640@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: |In article <1276@uwbull.uwbln.UUCP> ckl@uwbln.UUCP (Christoph Kuenkel) writes: |>Is there any way to alter the default environment setting used when |>rsh (the bsd remote shell) executes commands? |> |>our rsh (bull sps9 with spix os) sets up an default environment |> |HUH? (cr,h,...)ackers anyone? Isn't rsh RESTRICTED shell? Anyway, |why not just set these in .profile using standard UNIX syntax ala |HOME=/usr/mydirectory;export HOME |That is, if you have permissions on .profile. |Or is YOUR UNIX *different* than mine (AT&T)? Definitely. The guy said bsd. 'rsh' was also a surprise to me when I first worked in a System V environment. The BSD /bin/sh has also a notion of restriction, although I never saw it documented (not in sh(1) nor in S. R. Bourne's 'An Introduction to the UNIX Shell'). The following is run on an Vax running Ultrix: Script started on Sun Dec 25 13:15:02 1988 philmds> sh philmds> set -r philmds> pwd /usr/leo philmds> cd .. cd: restricted philmds> cd / cd: restricted philmds> cd News cd: restricted philmds> ls bin [my bin directory is listed]... philmds> /bin/ls bin /bin/ls: restricted philmds> ^Dphilmds> script done on Sun Dec 25 13:17:20 1988 Restriction seems to imply both not to be able to change the working directory and execute only commands that are found using $PATH (they may not contain a slash). I'm interested both in what restriction means in System V, and whether there is any documentation about -r (set -r, sh -r) for the BSD /bin/sh. Furthermore I'm interested in hearing about its use (for what, and how). Leo.
wnp@dcs.UUCP (Wolf N. Paul) (12/26/88)
In article <901@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > (demo of restricted shell deleted) >Restriction seems to imply both not to be able to change the working >directory and execute only commands that are found using $PATH (they >may not contain a slash). > >I'm interested both in what restriction means in System V, and whether >there is any documentation about -r (set -r, sh -r) for the BSD /bin/sh. >Furthermore I'm interested in hearing about its use (for what, and how). The following is from the manual page for sh(1) under System V R.2: -----beginning of quote Rsh is used to set up login names and execution environments whose capabilities are more controlled than those of the standard shell. The actions of rsh are identical to sh, except that the following are disallowed: changing directory setting the value of $PATH, specifying path or command names containing /, redirecting output (> and >>). These restrictions are enforced after .profile is interpreted. ... The net effect of these rules is that the writer of the .profile has complete control over user actions, by performing guaranteed setup actions and leaving -----end of quote Some notes: sh and rsh are links to the same binary, with "sh -r" being equivalent to an invocation of rsh. "set -r" after the shell has started also has the same effect, as Leo's demo showed. The manual further points out that shell scripts are executed using standard sh, thus the restriction can probably be gotten around. the user in an appropriate directory (probably not the login directory). -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
debra@alice.UUCP (Paul De Bra) (12/27/88)
In article <901@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >... >Definitely. The guy said bsd. 'rsh' was also a surprise to me when I >first worked in a System V environment. > >The BSD /bin/sh has also a notion of restriction, although I never saw >it documented (not in sh(1) nor in S. R. Bourne's 'An Introduction to >the UNIX Shell'). >... >I'm interested both in what restriction means in System V, and whether >there is any documentation about -r (set -r, sh -r) for the BSD /bin/sh. >Furthermore I'm interested in hearing about its use (for what, and how). > > Leo. The restricted shell "is used to set up login names and execution environments whose capabilities are more controlled than those of the standard shell" (System V user manual). There are (according to the manual) 4 things that are disallowed: - changing directory - setting $PATH - specifying path or command names containing / - redirecting output (both > and >>) The reason why the restricted shell is dying away is that it is SO easy to bypass... (Since most readers of this newsgroup have sufficient imagination to become a "cracker" but enough discipline to refrain from such activities I don't think I have to sketch a scenario to break out of the restricted environment) Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (12/28/88)
In article <901@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >I'm interested both in what restriction means in System V, and whether >there is any documentation about -r (set -r, sh -r) for the BSD /bin/sh. >Furthermore I'm interested in hearing about its use (for what, and how). > > Leo. In general, you would want to set up a restricted user, perhaps using the computer to operate automated equiptment. (Though I can't justify the need for a shell rather than a well written control program.) You would set up a sub-structure complete with a home directory and a home/bin directory. The user would (obviously) be placed in the home directory upon login, the PATH set to home/bin. (S)he could then use the commands/programs inside the home/bin directory, yet would not be able to change directory (to poke around the system, etc.) or use commands not authorized. -- These are my opinions and you can't have them. -- |\/| | | | _ |< / \_(_(_)\_/ \______
kai@uicsrd.csrd.uiuc.edu (12/29/88)
In responce to the original question, which was how to customize the environment on the remote machine using the BSD remote shell (rsh) command, if you use C shell, your remote .cshrc is sourced, but not your .login file. Setup what you want in your remote .cshrc file, for example: # ~/.cshrc if ($?prompt) then # setup for interactive shell alias bye logout else # for non-interactive shells, like rsh set path = ( /usr/local/bin /usr/ucb /bin /usr/bin . ) endif Patrick Wolfe (pat@kai.com, kailand!pat)
lyndon@auvax.uucp (Lyndon Nerenberg) (12/29/88)
In article <278@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: >Some notes: sh and rsh are links to the same binary, with "sh -r" being >equivalent to an invocation of rsh. "set -r" after the shell has started >also has the same effect, as Leo's demo showed. The manual further points out >that shell scripts are executed using standard sh, thus the restriction can >probably be gotten around. No kidding :-) Script started on Wed Dec 28 21:54:59 1988 (9:55pm) aurora:/nfs/aurora2/lyndon% sh -r $ pwd /nfs/aurora2/lyndon $ cd .. cd: restricted $ sh $ pwd /nfs/aurora2/lyndon $ cd .. $ pwd /nfs/aurora2 (9:55pm) aurora:/nfs/aurora2/lyndon% exit script done on Wed Dec 28 21:55:41 1988 The only way to make this work properly is to modify sh to always run restricted mode, and make sure the users path has this version of sh in front of /bin/sh. You can also make sh a disabled 'builtin' command when you're running restricted. Either way, shell scripts start to act strange ... -- Lyndon Nerenberg Computing Services Athabasca University {alberta, attvcr, ncc}!auvax!lyndon || lyndon@nexus.ca
debra@alice.UUCP (Paul De Bra) (12/31/88)
In article <425@aurora.auvax.uucp> lyndon@auvax.UUCP (Lyndon Nerenberg) writes: }In article <278@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: }>Some notes: sh and rsh are links to the same binary, with "sh -r" being }>equivalent to an invocation of rsh. "set -r" after the shell has started }>also has the same effect, as Leo's demo showed. The manual further points out }>that shell scripts are executed using standard sh, thus the restriction can }>probably be gotten around. } }No kidding :-) } }(9:55pm) aurora:/nfs/aurora2/lyndon% sh -r }$ pwd }/nfs/aurora2/lyndon }$ cd .. }cd: restricted }$ sh }$ pwd }/nfs/aurora2/lyndon }$ cd .. }$ pwd }/nfs/aurora2 }(9:55pm) aurora:/nfs/aurora2/lyndon% exit } Hold it! The restricted shell is intended to be used together with a small set of programs, put in a special directory, and with a $PATH that only goes through that directory. Furthermore, the programs for "restricted" users should not include editors (maybe just red), shells (rsh will find /bin/sh though /bin is not in $PATH) mail, etc. etc. etc... The sad part is that it is very difficult to find a useful set of commands that still does not allow the user to break out. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
buck@siswat.UUCP (A. Lester Buck) (12/31/88)
In article <425@aurora.auvax.uucp>, lyndon@auvax.uucp (Lyndon Nerenberg) writes: [ ...deleted trivial demo that "sh -r" still lets one execute sh ] > The only way to make this work properly is to modify sh to always run > restricted mode, and make sure the users path has this version of > sh in front of /bin/sh. You can also make sh a disabled 'builtin' > command when you're running restricted. Either way, shell scripts > start to act strange ... No, the way to use rsh is to understand how it should be set up. "Unix Shell Programming" by Kochan and Wood summarizes a sample rsh environment, typically for a game user or a data entry clerk. An rsh setup needs a .profile that sets a restricted path, say PATH=/usr/rbin:/usr/restrict/bin and set SHELL=/bin/rsh, then cd into /usr/restrict/bin. If the user trys to BREAK or DELETE out of the .profile at login, he is logged off. /usr/rbin is suggested to contain *only* cat, echo, ls, mail, red, and write. /usr/restrict/bin might have all the games or whatever application is to be run. Even this setup is described as "not really very secure." We can all imagine some interesting attacks. Just nothing as trivial as "$ sh". -- A. Lester Buck ...!uhnix1!moray!siswat!buck
bdb@becker.UUCP (Bruce Becker) (01/02/89)
In article <425@aurora.auvax.uucp> lyndon@auvax.UUCP (Lyndon Nerenberg) writes: > [ example of security hole in 'rsh' ] >The only way to make this work properly is to modify sh to always run >restricted mode, and make sure the users path has this version of >sh in front of /bin/sh. You can also make sh a disabled 'builtin' >command when you're running restricted. Either way, shell scripts >start to act strange ... In some versions of 'sh/rsh', the environment variable "$SHELL" is special - if it ends with the string 'rsh', then the restrictions are in force no matter whether one entered as 'sh' or 'rsh'. "$SHELL" becomes readonly as well. >Lyndon Nerenberg Computing Services Athabasca University >{alberta, attvcr, ncc}!auvax!lyndon || lyndon@nexus.ca Cheers, -- _ _/\ Bruce Becker Toronto, Ont. \`o O| Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu \(")/ BitNet: BECKER@HUMBER.BITNET ---mm-U-mm--- "The OSF is suffering from Penix envy" - Rocky Raccoon
lyndon@auvax.uucp (Lyndon Nerenberg) (01/03/89)
In article <193@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes: > > In some versions of 'sh/rsh', the environment variable > "$SHELL" is special - if it ends with the string 'rsh', > then the restrictions are in force no matter whether one > entered as 'sh' or 'rsh'. "$SHELL" becomes readonly as well. [ Alright already! The example I posted was a bit trivial :-) ] The above example is true for the SVR3 sh. I haven't seen it (working) in any version prior to that. The point is, most implementations of the restricted Bourne shell can be broken with not much more work than the example I gave. The SVR3 version takes more care in enforcing restriction. Anything that grabs a subshell via popen or system will stay within the rsh environment. As another poster mention, though, IFS can still be played with to interesting advantage, and if the user has write access to a directory, and the ability to generate a binary executable file (not necessarily using cc; emacs works just fine) he's got you via exec(2). The problem with rsh isn't really rsh, it's the wide variety of uses the standard Unix tools can be used for. Who needs cat when dd is there? as is redundent in the face of emacs (remember the definition of a wizard? :-) If rsh is used to provide a restricted news environment, you generally need to give the user an editor of some sort to compose articles with. How many of these editors check with the shell to determine if the save path specified is "allowed?" Etc. Wrapping the environment inside a chroot(2) helps, but it also increases administration headaches somewhat. I guess it's up to you to determine if your time is better spent monitoring the restricted environment versus writing an application wrapper to provide *only* the functions necessary for the job. -- Lyndon Nerenberg Computing Services Athabasca University {alberta, attvcr, ncc}!auvax!lyndon || lyndon@nexus.ca
pinkas@hobbit.intel.com (Israel Pinkas ~) (01/04/89)
In article <8636@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes: > In article <425@aurora.auvax.uucp> lyndon@auvax.UUCP (Lyndon Nerenberg) writes: > }In article <278@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: > }>Some notes: sh and rsh are links to the same binary, with "sh -r" being > }>equivalent to an invocation of rsh. "set -r" after the shell has started > }>also has the same effect, as Leo's demo showed. The manual further points out > }>that shell scripts are executed using standard sh, thus the restriction can > }>probably be gotten around. > Hold it! The restricted shell is intended to be used together with a small > set of programs, put in a special directory, and with a $PATH that only > goes through that directory. I think there is a problem here. There are two programs named rsh, who do do very different things. In the SysV environment, rsh is the restricted version of the Bourne Shell, which is a link to sh. Upon startup, the -r flag is set. This program and the flag are not available in the BSD versions of sh that I checked (Ultrix and SunOS). In the BSD environment, rsh is the remote shell, a companion of rlogin and rcp. SysV machines that have these commands often call this program rcmd, for remote command. I believe that the original question was how to pass portions of the environment when executing a remote shell. In this context, I believe that the BSD version of the program is what we should be talking about. I have aliases that do this. They all execute a command such as: rsh mach "setenv FOO foo; setenv BAR bar; cmd1; cmd2" Hope this helps. -Israel -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cad001!pinkas ARPA: pinkas%cad001.intel.com@relay.cs.net CSNET: pinkas@cad001.intel.com