neville@ads.arpa (01/28/87)
i've just been trying to decide whether to password some accounts on our system that run special programs instead of a normal shell. If a program, e.g. a bulletin-board system, does not allow shell escapes is it relatively secure even if it doesn't run in a chroot'd environment? i'm sure most of you can think of the more apppriate examples that i'm reluctant to mention here. The director of our lab leans toward the paranoid side, and is sure that such password entries represent holes that need to be plugged. Thanks. -neville ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ U.S. Mail: Neville D. Newman Advanced Decision Systems 201 San Antonio Circle, Suite 286 Mountain View, CA 94040-1289 Phone: (415) 941-3912 Net mail: neville@ads.arpa (internet-relative)
decot@hpisod2.UUCP (02/03/87)
> i've just been trying to decide whether to password some accounts on our > system that run special programs instead of a normal shell. If a program, > e.g. a bulletin-board system, does not allow shell escapes is it relatively > secure even if it doesn't run in a chroot'd environment? As long as it doesn't run such programs as more(1) or ex(1), either, since they can be used to get someplace where a shell escape is available. A bulletin board system is rather clumsy without a text editor, but it is currently impossible to tell more(1) or vi(1) to disallow shell escapes. In general, the fewer outside programs the application permits the user to use, the more secure such applications are. Dave Decot hpda!decot
robert@gitpyr.UUCP (02/05/87)
>decot@hpisod2.HP (Dave Decot) (decot@hpisod2.HP, <2590002@hpisod2.HP>): > > i've just been trying to decide whether to password some accounts on our > > system that run special programs instead of a normal shell. If a program, > > e.g. a bulletin-board system, does not allow shell escapes is it relatively > > secure even if it doesn't run in a chroot'd environment? > > As long as it doesn't run such programs as more(1) or ex(1), either, since > they can be used to get someplace where a shell escape is available. A > bulletin board system is rather clumsy without a text editor, but it is > currently impossible to tell more(1) or vi(1) to disallow shell escapes. Actually, you can "disable" shell escapes from more(1) or ex(1) or any other program that follows conventions by simply setting the SHELL environment variable to a null program before executing the program. I'd recommend /bin/true, but vi(1) on our system doesn't seem to like shell scripts as shells; an alternate could be /bin/sync, which is another command that ignores arguments, returns a "good" status and doesn't do anything apparent to the user. This is a kludge, true, but it works and can be quite valuable if you are a binary-only site. Watch out for programs that allow shell escapes but ignore SHELL, though. I don't know of any that do, but that doesn't mean they don't exists. They're anti-social anyway. robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332
wcs@ho95e.UUCP (02/08/87)
There's been a discussion on providing restricted environments without using chroot, and how to deal with shell escapes from editors, BBSs, more,... In article <3037@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >Actually, you can "disable" shell escapes from more(1) or ex(1) or any >other program that follows conventions by simply setting the SHELL >environment variable to a null program before executing the program. >..... >Watch out for programs that allow shell escapes but ignore SHELL, though. >I don't know of any that do, but that doesn't mean they don't exist. >They're anti-social anyway. The "system(3)" subroutine call does this, at least on V7, 4.1BSD, and System V Release 0 and 2. A lot of commands use it, including /bin/mail. Aside from being anti-social (4.*BSD and SVR2 are old enough to know better), it can also be a source of bugs and/or security risks. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
rem@remsit.UUCP (02/08/87)
In article <3037@gitpyr.gatech.EDU>, robert@gitpyr.gatech.EDU (Robert Viduya) writes: > >decot@hpisod2.HP (Dave Decot) (decot@hpisod2.HP, <2590002@hpisod2.HP>): > > > i've just been trying to decide whether to password some accounts on our > > > system that run special programs instead of a normal shell. If a program, > > > > As long as it doesn't run such programs as more(1) or ex(1), either, since > > they can be used to get someplace where a shell escape is available. A > > bulletin board system is rather clumsy without a text editor, but it is > > currently impossible to tell more(1) or vi(1) to disallow shell escapes. > > Actually, you can "disable" shell escapes from more(1) or ex(1) or any > other program that follows conventions by simply setting the SHELL > environment variable to a null program before executing the program. What's to stop somebody from going into vi and typing ":set shell=/bin/csh"? It's a shame they wrote red and not rvi, I think. I'd love to set up vi for similar reasons but can't because anyone could fork a shell (any shell they felt like, more or less). Of course, it's pretty silly to write a restricted version of every program on the system (rgrep?, rawk?, rcc?, /rxenix?!? :-) My only suggestion would be to get the source code to a reasonably good editor and patch it for use with the BBS. At the very worst, there is red to fall back on. -- Roger Murray UUCP: ...!{ihnp4,randvax,sdcrdcf,ucbvax}!ucla-cs!cepu!ucla-an!remsit!rem ARPA: cepu!ucla-an!remsit!rem@LOCUS.UCLA.EDU
neil@sunybcs.UUCP (02/08/87)
In article <3037@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes:
->Actually, you can "disable" shell escapes from more(1) or ex(1) or any
->other program that follows conventions by simply setting the SHELL
->environment variable to a null program before executing the program.
-> ......
->Watch out for programs that allow shell escapes but ignore SHELL, though.
->I don't know of any that do, but that doesn't mean they don't exists.
->They're anti-social anyway.
You also have to worry about the EDITOR envariable as well.
Restricting someones shell but allowing them to choose their editor is
just as dangerous as allowing them to run the shell of their choice.
I don't know, but perhaps some programs use the VISUAL envariable for
a visual editor as well.
Neil
Neil Smithline
csnet: neil@buffalo.CSNET
uucp: ..!{allegra,ames,decvax,watmath}!sunybcs!neil
bitnet: neil@sunybcs.BITNETdce@mips.UUCP (02/09/87)
In article <1317@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-#Bill.Stewart,2G202,x0705,) writes: >In article <3037@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >>Watch out for programs that allow shell escapes but ignore SHELL, though. >>I don't know of any that do, but that doesn't mean they don't exist. >>They're anti-social anyway. > >The "system(3)" subroutine call does this, at least on V7, 4.1BSD, and >System V Release 0 and 2. A lot of commands use it, including /bin/mail. >Aside from being anti-social (4.*BSD and SVR2 are old enough to know better), >it can also be a source of bugs and/or security risks. >-- ># Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs I'm not quite sure what Bill means here, but it appears that he is saying that he feels that it is improper for system(3) to ignore the value of SHELL. If this is the case, then I have to strongly disagree. When I write a program that uses system(), I am assuming that it will use /bin/sh. Without that assumption, the most I can expect to execute is a command like command 'arg1' 'arg2' ... < 'infile' > 'outfile' and I'm expecting a lot here (command execution syntax, quoting, and redirection must be sh-compatible, so any kind of new shell, such as a Lisp-based shell, would be out of the question). (You might argue that the quoting doesn't matter, but that's another discussion.) And, if all I can expect is the above, I'm much better off writing a fork/redirect/exec subroutine than using system(), for better speed and control. The idea of using the SHELL environment variable is something that really wreaks havoc when you port the System V.2 or better version of make(1) to a BSD system (or use it in System V.3). Take a look around and count how many makefiles would break if run using csh instead of sh. The person that came up with this method really needs a talking to. We ended up changing sh to not import the value of SHELL from the environment. If a makefile needs to use a different shell, it should be specifiable on a per-makefile basis, instead of having the user screw something up unknowingly. shell, the user can just -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700
gwyn@brl-smoke.UUCP (02/09/87)
In article <1317@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-#Bill.Stewart,2G202,x0705,) writes: -In article <3037@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: ->Watch out for programs that allow shell escapes but ignore SHELL, though. -The "system(3)" subroutine call does this, at least on V7, 4.1BSD, and -System V Release 0 and 2. A lot of commands use it, including /bin/mail. -Aside from being anti-social (4.*BSD and SVR2 are old enough to know better), -it can also be a source of bugs and/or security risks. Quite the contrary, it is essential for system(3) to provide a well-behaved set of semantics in order to NOT create a security hole. Allowing its behavior to depend on an environment variable would break many programs.
robert@gitpyr.UUCP (02/09/87)
>dce@quacky.UUCP (David Elliott) (dce@quacky.UUCP, <169@quacky.mips.UUCP>): > > The idea of using the SHELL environment variable is something that > really wreaks havoc when you port the System V.2 or better version > of make(1) to a BSD system (or use it in System V.3). Take a look > around and count how many makefiles would break if run using csh > instead of sh. The person that came up with this method really needs > a talking to. We ended up changing sh to not import the value of > SHELL from the environment. If a makefile needs to use a different > shell, it should be specifiable on a per-makefile basis, instead > of having the user screw something up unknowingly. > shell, the user can just > On a 3B20 running SVR2.0v2, the shell IS specifiable on a per makefile basis. Just include "SHELL=/bin/sh" near the beginning of the makefile. I'm fairly sure the same applies to SVR3.0 (can't tell right now, my 3B2 died of a power failure last night and I haven't brought it back up yet). According to the manual page, macro definitions in the makefile are processed AFTER the environment variables are processed, which means that macro definitions override environment variables where-ever a conflict occurs. (Unless, of course, you use the -e option.) robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332
gwyn@brl-smoke.UUCP (02/11/87)
In article <3063@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >Just include "SHELL=/bin/sh" near the beginning of the makefile. The problem is, you HAVE to do this or you run the risk of having the Makefile break. "Make" has no business providing variable semantics for Makefiles dependent on the user's environment. I suppose the original reason for this in Augmented Make was to permit redefining CC for cross-compilation, etc. without having to edit zillions of Makefiles. Too bad SHELL is honored too.
robert@gitpyr.UUCP (02/12/87)
>gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) (gwyn@brl.arpa, <5615@brl-smoke.ARPA>): > In article <3063@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: > >Just include "SHELL=/bin/sh" near the beginning of the makefile. > > The problem is, you HAVE to do this or you run the risk of having > the Makefile break. "Make" has no business providing variable > semantics for Makefiles dependent on the user's environment. I > suppose the original reason for this in Augmented Make was to > permit redefining CC for cross-compilation, etc. without having > to edit zillions of Makefiles. Too bad SHELL is honored too. I disagree completely. Adding "SHELL=/bin/sh" is an extremely trivial sacrifice to do compared to the flexibility it gives. The Bourne shell is not, nor should ever be considered as, the be-all-and-end-all of all shells. If I want to use Korn shell constructs in my Makefile, then there ought to be a general, clean way of doing it, such as "SHELL=/bin/ksh". Putting "/bin/ksh -c <cmd>" on every command line in the Makefile is an ugly kludge. If Joe User down the hall only knows how to write csh shell scripts and wants to do something more than just sequential command execution in a Makefile (such as loops), he doesn't have to learn how to use the Bourne shell to do so. robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332
guy@gorodish.UUCP (02/13/87)
>If I want to use Korn shell constructs in my Makefile, then >there ought to be a general, clean way of doing it, such as >"SHELL=/bin/ksh". That ain't general - the Korn shell is in "/usr/local/ksh" on my machine, and there may not *be* a Korn shell on other machines (which means there *is* no general way to use Korn shell constructs in your Makefile - period). Furthermore, it is a botch to *import* SHELL from the environment; this causes Makefiles to work differently for people with different login shells! "make" should NOT import SHELL; if people insist on being able to use other shells, perhaps it should allow you to change SHELL from within the Makefile and ONLY from within the Makefile.
dce@mips.UUCP (02/13/87)
In article <3088@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >>gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) (gwyn@brl.arpa, <5615@brl-smoke.ARPA>): >> In article <3063@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >> >Just include "SHELL=/bin/sh" near the beginning of the makefile. >> The problem is, you HAVE to do this or you run the risk of having >> the Makefile break. "Make" has no business providing variable >> semantics for Makefiles dependent on the user's environment. I >> suppose the original reason for this in Augmented Make was to >> permit redefining CC for cross-compilation, etc. without having >> to edit zillions of Makefiles. Too bad SHELL is honored too. >I disagree completely. Adding "SHELL=/bin/sh" is an extremely trivial >sacrifice to do compared to the flexibility it gives. The Bourne shell >is not, nor should ever be considered as, the be-all-and-end-all of all >shells. If I want to use Korn shell constructs in my Makefile, then >there ought to be a general, clean way of doing it, such as >"SHELL=/bin/ksh". Putting "/bin/ksh -c <cmd>" on every command line in >the Makefile is an ugly kludge. If Joe User down the hall only knows >how to write csh shell scripts and wants to do something more than just >sequential command execution in a Makefile (such as loops), he doesn't >have to learn how to use the Bourne shell to do so. I don't disagree with being ABLE to use a different shell, but I disagree with the method that was used to implement it. As Doug says, it isn't right that I have to edit already-working makefiles just because AT&T decides to allow the SHELL variable. Maybe you don't have 300-400 makefiles to maintain (I'd bet that Doug has thousands), but some of us do, and don't like the idea of having to change every one of them just to make them work again (note the operative word is "again"). What I really dislike about this implementation is that it assumes that the default should be whatever my SHELL variable is, as opposed to the shell that the makefile is written for. If SHELL is to be used by make, the only proper way to do it is to require that it be set in the makefile, but that for backwards compatability (or is it no longer desirable to satisfy customers) the default should be /bin/sh. The problem isn't that SHELL is used, but that it's imported from the environment. There's nothing in the makefile syntax that says that the line SHELL=program is required. Yet, for all practical purposes, it is. No one is asking anyone to give up any flexibility. All Doug and I wish is that someone familiar with software development problems had actually examined the situation before blindly implementing what has turned out to be a bad solution. -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700
clive@druhi.UUCP (02/18/87)
Probably, I don't have the gruedom to know why something like this
won't quickly 'automaintain' all those 'thousands of makefiles' to say
what their shell should be:
find interestingdir \
\( -name Makefile -o -name makefile -o -name \*\.mk \) (etc.) \
-exec addshellname {} \;
where addshellname does something like
echo "SHELL=/bin/sh" > /tmp/${$}
cat ${@} >> /tmp/${$}
cp /tmp/${$} ${@}
rm /tmp/${$}
Frankly, it would probably be a good idea all around, given the
experiences I've had with ksh, for instance, breaking makes.
Especially on small memoried machines.
Users should be able to use any shell; and Makefiles also, not
necessarily the same one.
Always put that line in, myself.guy@gorodish.UUCP (02/19/87)
>Probably, I don't have the gruedom to know why something like this >won't quickly 'automaintain' all those 'thousands of makefiles' to say >what their shell should be: Well, maybe it would, but why should it be *necessary*? I can think of a lot of changes to the shell, say, that might be nice to make, but would require something like this to be done. >Frankly, it would probably be a good idea all around, given the >experiences I've had with ksh, for instance, breaking makes. No, it wouldn't be a good idea; the good idea would be to tell "make" not to import SHELL from the environment! >Users should be able to use any shell; and Makefiles also, not >necessarily the same one. Fine, just have "make" use the Bourne shell by default, as it did before S3.
dave@onfcanim.UUCP (02/19/87)
In article <1684@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: > > find interestingdir \ > \( -name Makefile -o -name makefile -o -name \*\.mk \) (etc.) \ > -exec addshellname {} \; Unfortunately, it won't find things like "Makefile.v7" and "Makefile.usg" which are the "master" makefiles for some software. It also won't find "makefile.old" or a makefile that is packed into a shar or tar or compress file. I'd much prefer to fix make so it behaves in a way that seems reasonable. Importing SHELL from the environment does not seem reasonable. (Neither does importing TERMCAP, but at least that doesn't actively break anything).
dce@mips.UUCP (02/20/87)
In article <1684@druhi.UUCP> clive@druhi.UUCP (Clive Steward) writes: >Probably, I don't have the gruedom to know why something like this >won't quickly 'automaintain' all those 'thousands of makefiles' to say >what their shell should be: > code example > >Frankly, it would probably be a good idea all around, given the >experiences I've had with ksh, for instance, breaking makes. >Especially on small memoried machines. > >Users should be able to use any shell; and Makefiles also, not >necessarily the same one. You're missing the point. The "grue"s (how do you like being called a "grue", Guy?) that are arguing against the change could easily write commands that add a SHELL=/bin/sh line to the beginning of each makefile, but why should they have to? Think about us people with BSD-based systems, where the fact that most users still use csh causes even more problems (you think ksh breaks bad?). We'd like to have the features of the AT&T make, but can't afford to go into every user's makefiles and make the change (announce it on news, you say? Half of the people here don't even read their mail!). Once more, I must bring up the point of customers. Mips is in the OEM business, so most of our customers sell our systems to other people. What are we supposed to do? "Hello. This is Bill at Jim's Computer Systems. Why does make do ...?" "Well, Bill, you need to to put a SHELL=/bin/sh at the top." "We lost the XYZ CAD account because the software wouldn't build. We're suing." One final question: how would you like it if AT&T changed all of the shells such that they use $SHELL to run your shell scripts by default? Do you write all of your shell scripts entirely without ksh builtins? Do you expect everyone to? -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700
mouse@mcgill-vision.UUCP (02/20/87)
In article <2590002@hpisod2.HP>, decot@hpisod2.HP (Dave Decot) writes: > As long as it [a special `shell' with an escape to a real shell] > doesn't run such programs as more(1) or ex(1), either, since they can > be used to get someplace where a shell escape is available. Except that the shell escaped to would be a copy of the special shell, no? This is certainly the case here with one program we have. We have an Ultrix system, which has a program dlogin to perform remote logins over DECnet (don't ask why we're running DECnet, you don't want to know). We wanted a pseudo-user which just prompted for a hostname and ran dlogin. However, dlogin has a shell escape. But when it's used, all you get is another hostname prompt! > In general, the fewer outside programs the application permits the > user to use, the more secure such applications are. This is pretty tough to argue with. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!musocs!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu