root@raider.UUCP (Bob Reineri) (08/14/88)
I am rapidly finding out that running a public access system is a security
nightmare. I am currently having a couple of problems :-), perhaps someone
may be able to help.
I would like to give folks access to vnews and elm via a restricted shell. I
have dutifully set up a 'restricted' bin directory containing just a few
commands, like vi, vnews, readnews, who, cat; I set all restricted users PATH
to this directory only. Here's the rub:
They can use shell commands from within either vnews of vi and do anything
their heart desires (within normal system security, of course). Well, this
just won't work ! I know there is a 'red' editor, but I hate to confine them
to that.
Does anyone have a solution for me ? Am I trying to do this the wrong way ?
Bob
--
______
/ / RaiderNet Public Access - Node 2 (Xenix) (615) 896-8716
/_____/ ___ o ___ ___ ___ * Murfreesboro, Tennessee *
/ \ /__/ / / / /__ /__/ * Middle Tennessee's Gate *
_/ \___/ /__/__/__/__/__ __/ \_ * Node 1 (615) 896-7905 (DOS)*
UUCP: !{ames,osu-cis,rutgers,decwrl,mit-eddie}!killer!raider FIDO:1:116/12davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/19/88)
What you need for security falls into a number of areas. uucp security
was addressed in my posting of a few days ago (I absolutely can't mail
any more copies), so here are a few more ideas.
For shell you could run Korn shell (ksh). By setting the PATH variable
and then making it readonly, and using the restricted shell, you can
control what can be executed.
For an editor, I use microemacs in restricted mode. This allows me to
set which command I allow, and to tailor the key maps any way I want.
Finally you can use chroot to place the user in a virtual machine.
There are some problems with this as far as having multiple copies of
software, or having news in its own partition, etc. I run guest users in
a restricted shell, but at one time I had a complete environment
accessable to any caller. I won't claim it was bulletproof, but in a
year no one broke out.
You have to find a balance between having great security and the time
it takes to administer a secure system. Someone has to check fancy logs
if you add them, to keep copies of software in sync, to add and delete
things in the secure environment, etc.
I don't have all the answers, but if you find some way to have a
secure system which isn't more trouble to support, do let me know.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merick@pcrat.UUCP (Rick Richardson) (08/19/88)
In article <4@raider.UUCP> root@raider.UUCP (Bob Reineri) writes: >I am rapidly finding out that running a public access system is a security >nightmare. I am currently having a couple of problems :-), perhaps someone >may be able to help. Start off by using the chroot feature of login (System V). Then, the clowns that login can only stomp on each others files, and not your root and personal user areas, should there be security holes you haven't plugged. Setting up the chroot area is a pain in the butt, but worth it given the cracker spirit so prevalent today. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
det@hawkmoon.MN.ORG (Derek E. Terveer) (08/25/88)
In article <4@raider.UUCP>, root@raider.UUCP (Bob Reineri) writes: > They can use shell commands from within either vnews of vi and do anything > their heart desires (within normal system security, of course). Well, this > just won't work ! I know there is a 'red' editor, but I hate to confine them > to that. (i know you didn't mention less, but here's my 2 cents anyway) I can't help with vnews or vi (i wish there was an "rvi" ! (for those of us w/o the source code that is!)), but if you happen to let them use less, the public domain version (4.0, i believe) has a compile time option that allows/disallows shell escapes. Simply turn this off. (0) derek -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 "A proper king is crowned" -- Thomas B. Costain
brad@looking.UUCP (Brad Templeton) (08/28/88)
Probably the best way to provide security is to make a mini filesystem
and chroot the users to it. You must create directories there like /etc,
with a special /etc/passwd and /etc/group file there for the restricted
users. Plus a /dev, and a /tmp, a /bin, /usr/bin. In most cases (not passwd)
you can just use a link from the real filesystem, as long as the file you
want is in the same filesystem as the restricted one. You can give people
A vi, a kermit, csh, all those things.
Only link in the commands you really want to give restricted users, and
take extra care that for any setuid command you provide, that *all the required
files and directories* are in place in the /tiny filesystem and not generally
writable.
Don't forget things like /dev/tty, and /usr/preserve (for vi) although reboot
preserve processing won't go on there.
Now I haven't investigated it a lot, so maybe there are holes in chroot.
Assuming not, however, it should let you custom configure any restricted
environment you want. (Some things, like mail and news will be tougher.
You will have to include the news lib and spool directories inside the
tiny directory, and have special compilations of the news programs.)
(If anybody does know a hole in chroot, let me know!)
Here's the source for something you can use as the login shell of a
restricted user.
----------
/*
* Set up a login in the chroot directory
*/
main( argc, argv, envp )
int argc;
char **argv;
char **envp;
{
int ruid;
ruid = getuid();
chroot( "/tiny" );
setuid( ruid );
argv[argc] = 0; /* to be sure */
execve( "/bin/csh", argv, envp );
}
---------
--
Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473elt@entire.UUCP (Edward L. Taychert) (08/29/88)
In article <4@raider.UUCP>, root@raider.UUCP (Bob Reineri) writes: > They can use shell commands from within either vnews of vi and do anything > their heart desires (within normal system security, of course). Well, this > just won't work ! I know there is a 'red' editor, but I hate to confine them > to that. > -- I created an /rbin for my guest users and only included (link'ed) in those commands I wanted them to use. I was particularly concerned about the escape in mail. Anyway, by denying them write access to their profiles and limiting their paths to rbin. I think I've implented fair security. (to the best of my knowledge, no-ones broken it... but don't keep anything sensitive on the system.) The only shell I keep in /rbin is rsh. It seems that I don't allow guest users to do very much, but its enough to implement a bbs like system. I belive I tried out VI and it was secure this way, but I don't give them VI because its so complicated... I have a stripped down micro-emacs I provide. -- ____________________________________________________________________________ Ed Taychert Phone: USA (716) 381-7500 Entire Inc. UUCP: rochester!rocksanne!entire!elt 445 E. Commercial Street East Rochester, N.Y. 14445 _____________________________________________________________________________
tif@cpe.UUCP (09/01/88)
Written 10:24 am Aug 14, 1988 by raider.UUCP!root in cpe:comp.unix.xenix >I would like to give folks access to vnews and elm via a restricted shell. I >have dutifully set up a 'restricted' bin directory containing just a few >commands, like vi, vnews, readnews, who, cat; I set all restricted users PATH >to this directory only. Here's the rub: > >They can use shell commands from within either vnews of vi and do anything >their heart desires (within normal system security, of course). Well, this >just won't work ! I know there is a 'red' editor, but I hate to confine them >to that. > >Does anyone have a solution for me ? Am I trying to do this the wrong way ? Experiment with the environment variable, SHELL. I have a limited login which sets SHELL="". It effectively prevents shell escapes from most programs. You might be satisfied with setting SHELL=rsh. Paul Chamberlain Computer Product Engineering, Tandy Corp. {convex,killer}!ninja!cpe!tif
deraadt@xenlink.UUCP (Theo A. DeRaadt) (09/10/88)
In article <288@hawkmoon.MN.ORG>, det@hawkmoon.MN.ORG (Derek E. Terveer) writes: > In article <4@raider.UUCP>, root@raider.UUCP (Bob Reineri) writes: > > They can use shell commands from within either vnews of vi and do anything > > their heart desires (within normal system security, of course). Well, this > > just won't work ! I know there is a 'red' editor, but I hate to confine them > > to that. ... > I can't help with vnews or vi (i wish there was an "rvi" ! (for those of us w/o > the source code that is!)), but if you happen to let them use less, the public > domain version (4.0, i believe) has a compile time option that allows/disallows > shell escapes. Simply turn this off. (0) What you want to do is write a wrapper for each program they use that does the approximately the following: /* this program is called "umacs", in some other directory that rsh has * access to. It is really actually "umacs_wrapper" */ #define REAL_PROGRAM "/usr/bin/umacs" #define NEWENV 2 char table[NEWENV][] = { /* whatever you want */ "SHELL=/bin/echo", "USERNAME=idiot" }; main(argv, argc, envp) char *argv[]; int argc; char *envp[]; { int i, j; char **newenv; for(i=0; envp[i]; i++) ; newenv = (char **)malloc( (i+NEWENV) * sizeof(int)); for(j=0; j<NEWENV; j++) /* ours first, sequential search */ newenv[j] = table[j]; for(i=0; envp[i]; i++) newenv[i+NEWENV] = envp[i]; argv[0] = REAL_PROGRAM; execv(argv, argc, newenv); } Basically........, this is what it does: It copies the old process environment after a new one that we have set up, which makes the user have a restricted environment. Look at the table and see what I make his 'shell' - this means that if from umacs he does an 'pause-emacs' he will get almost nowhere! One thing for you to deal with - I have been up for 24 hours now, and I am going to sleep now - but this should give you the basics and maybe you can do it yourself or reach someone else who can read the manuals and figure it out. The basics are there........ ZZZZzzzz.... --- _____ _ ------------------------------------- / / / / \ _ _ /_/_ Theo de Raadt: (403) 289-4620 / /_ _ ___ __/_ /__/ _\ _\ __/ / Xenix386 login: (403) 295-2541 / / /</_(_) (_/</_/ \_(_/\(_/\(_/_(_/ ihnp4!alberta!calgary!xenlink!deraadt
jpr@dasys1.UUCP (Jean-Pierre Radley) (09/24/88)
In article <6800030@cpe> tif@cpe.UUCP writes: >Written 10:24 am Aug 14, 1988 by raider.UUCP!root in cpe:comp.unix.xenix >>I have ... set up a 'restricted' bin directory containing just a few >>commands ... I set all restricted users PATH to this directory only. >>Here's the rub: >> >>They can use shell commands from within either vnews or vi... > >Experiment with the environment variable, SHELL. I have a limited >login which sets SHELL="". It effectively prevents shell escapes from >most programs. You might be satisfied with setting SHELL=rsh. > > Paul Chamberlain The rub in that last answer is the "most". The desire would seem to be to prevent shell escapes from ALL programs, and 'vi' is a particularly nasty culprit properly in that regard: Whatever you set SHELL to, vi has its own "sh" parameter, and you can't just tell the users to type :set sh=/bin/rsh. A solution for a restricted vi was devised by Fred Buck, and can be found in the LIBraries of the TANGENT Forum on Compuserve. If there is a feeling that it should be posted here, I will ask Fred for permission to do so. -- Time is nature's way of Jean-Pierre Radley making sure that everything ..!cmcl2!phri!dasys1!jpr doesn't happen all at once. CIS: 76120,1341
tif@cpe.UUCP (09/27/88)
Written 2:47 pm Sep 23, 1988 by dasys1.UUCP!jpr in cpe:comp.unix.xenix >In article <6800030@cpe> tif@cpe.UUCP writes: >>Experiment with the environment variable, SHELL. I have a limited >>login which sets SHELL="". It effectively prevents shell escapes from >>most programs. You might be satisfied with setting SHELL=rsh. > >The rub in that last answer is the "most". The desire would seem to be >to prevent shell escapes from ALL programs, and 'vi' is a particularly >nasty culprit properly in that regard: Whatever you set SHELL to, vi >has its own "sh" parameter, and you can't just tell the users to >type :set sh=/bin/rsh. That is not the case on my system. I just tried it to make sure. I did SHELL="" export SHELL vi Then from vi, ":sh" didn't work, ":!ls" didn't work, and even "!!ls" didn't work. I also did ":set all" which said "shell=". Oops. Come to think of it, you could set shell to anything you want from within vi (i.e. ":set shell=/bin/sh"). So much for my secure login. Paul Chamberlain Computer Product Engineering, Tandy Corp. {convex,killer}!ninja!cpe!tif
jpr@dasys1.UUCP (Jean-Pierre Radley) (10/03/88)
In article <6800040@cpe> tif@cpe.UUCP writes: >Written 2:47 pm Sep 23, 1988 by dasys1.UUCP!jpr in cpe:comp.unix.xenix >>.... The desire would seem to be >>to prevent shell escapes from ALL programs, and 'vi' is a particularly >>nasty culprit properly in that regard: Whatever you set SHELL to, vi >>has its own "sh" parameter, and you can't just tell the users to >>type :set sh=/bin/rsh. > >That is not the case on my system. I just tried... > SHELL="" > export SHELL > vi >Then from vi, ":sh" didn't work, ":!ls" didn't work, and even "!!ls" >didn't work. I also did ":set all" which said "shell=". > >Oops. Come to think of it, you could set shell to anything you want >from within vi (i.e. ":set shell=/bin/sh"). So much for my secure login. That's just the point, Paul. Going in to 'vi', its internal 'sh' value is set to the environment variable SHELL, if it exists, or to /bin/sh if not. But either directly with ':se sh=I/m/gonna/get/outta/here', or via an .exrc file or an EXINIT environment variable, users can worm their way out of vi... And using 'readonly' in place of 'export' don't do ya no good whatsohowever for dis particular problemo. I'm waiting for an OK from Fred Buck to send up his 'rvi' solution, unless he wishes to post it himself. In security matters, as in warfare, the offense is usually ahead of the defense. -- Time is nature's way of Jean-Pierre Radley making sure that everything ..!cmcl2!phri!dasys1!jpr doesn't happen all at once. CIS: 76120,1341