From: root@rwsys.wimsey.bc.ca (Superuser)
Newsgroups: comp.unix.programmer
Subject: Re: Revisited: How to isolate a user... setuid()..?
Date: 13 Dec 92 06:15:46 GMT
Organization: RWSYS Exporter BBS system

cbaker@woody.dep.anl.gov (Christopher Baker) writes:
> 
> I posted this a while back and got very little response.
> I am re-posting this in hope that someone can help.
> All help would be greatly appreciated!
> 
> I run a BBS which runs under SCO Xenix.  The BBS software
> is accessed by loging into the Unix box through a single
> login with no password.  The BBS host actually takes care
> of each individuals login and password.  The host and all
> of its associated files and directories are owned by BBS
> and have a group of BBS.  So to unix, all the users of the
> BBS have the same login (bbs) and group id (bbs).
> 
> The host software actually replaces the shell.  The host
> actually allows for external programs to be run.  I have
> tested, and they work fine, programs like telnet and vi
> from the host.
> 
> This is the problem, programs like VI, Kermit, and telnet
> allow for shell escapes. Since every user has the same unix 
> level access, this is a gaping security hole, espcially
> when all of the bulletin board files are owned 
> by user BBS.  So with a single swoop, all of the bbs files
> can be elimated.
> 
> How could I create a black hole (isolated directory),
> use setuid(), or some other solution from a script or
> a small compiled program?
> 
> I immagined either some way of temp. setting the user id to some
> bogas id, moving to a directory and then changing permissions,
> or somehow changing the permissions on a temp. moved to file system.
> 
> I am not a programmer and the documentation on setuid()
> and the like are very poor.  Can anyone give me some explicit ways
> of fixing this?
> 
> Thank You in Advance,
> Christopher Baker
> 
> PS - Direct mail responses are welcome!
> 
> 
> Re: How to isolate a user...setuid()?
> 
> 
If your BBS program reads the enviornment from .profile, you can set the
SHELL enviornmental variable to the path of your BBS executable. Many
applications use this enviornment to determine what shell to offer
when the user presses the keys to invoke a shell. Then when the user
does a shell escape, it will be the BBS that comes up.

Not all programs use the enviornment in order to determine the path of
the shell program. Often it is hardcoded into the application. In such
a case, if you do not wish to tinker with the source code for the application
( or cannot ), perhaps you can set the path enviornment for the BBS to
first try some off the wall directory that offers a setuid program
by the name of sh or csh or whatever. This program will call the
real sh after it re-sets the uid to something you would prefer. 

--- cut here ----
/* fakesh.c
 * compile with:
 * cc fakesh.c -o sh
 * The executable will be named sh. Stick it in 
 * directory /fakebin or some other non-used directory
 * make this program run setuid to some account name that
 * can't damage your files. Then point the first subdirectory
 * in your BBS's PATH= enviornmental variable to this
 * subdirectory.
 */
main()
{
	/* call the real shell */
system( "/bin/sh" );
}
--- cut here ----

Even this will not catch the shell escapes on all applications. This is
the biggest problem with security on *nix BBS's. It is the leaky applications.
Best solution is get into the source code for the applications and fix 
versions of them for your BBS.
Randy Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
root@rwsys.wimsey.bc.ca (Randy Wright)      | Exporter BBS     2400 bps
                or                          | (604) 581-0518     8N1
    Randy_Wright@Mindlink.bc.ca             | uucp         ogin: uguest
                                            | interactive login: guest
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~