WizShell Security
-----------------
The wsh only has the ability to control file securities by what is
typed in at the wsh prompt. Any executables that it starts up that
allow the user to alter/view files other than those specified at the
wsh command-line are unsecure. An example of a problem that could
occur is with a program like vi. The user can start up 'vi' on a
file that they have permissions to, but then do something like
:w /usr/b/bob/.rhosts
and write over the .rhosts file in the WizPort administrator's
home directory (assuming that it is /usr/b/bob) and thereby possibly
gain access to the account running the WizPort. Or, a more obvious
security breach would be to make a shell (like csh) available to
wsh users. Then they could merely run the shell and ALL security
would be lost. The wsh security is done by limiting what commands
can be typed in at the command line. Any non-shell command (that
actually runs a program) should be of the form:
<command> [ <file> | <flags> ]*
For example: ls -alg /obj/cows/ ~jubal/moo.c
^ ^ ^ ^
| | | |
command args directory file
After successful login the wsh does four things:
1) Limit access to executables
Only executables in the wsh bin/ can be run as the command
2) Limit files to be in the fake root
3) Limit files according to read and write access
4) Disallow '/' in flags (to avoid flags like -f../../../../usr/b/bob/.rhost)
For a more detailed explanation of this system, read the technical chapter.
This document explains the non-technical aspect of security in two parts,
how to set up the security, and then security issues such as unsecure programs.
How to set up security
----------------------
There are two main aspects of security, the bin/ and etc/ directories.
The bin/ directory contains all the programs that the wsh user has access
to besides the built in shell commands (like alias, history, cd, etc..)
ONLY SECURE PROGRAMS SHOULD GO IN THIS DIRECTORY! Since the location
of this directory is configurable, you should make sure to put it somewhere
outside of the fake root directory. Otherwise, a breach in the file security
could mean a breach in your machine's security. This could be done a number
of ways, depending on what resources you make available, but the simplest
example is by adding /bin/csh in an executable script in bin/ (scripts in
bin/ will run the ACTUAL programs from the machine's root, not from the
fake root). If the bin/ is outside the fake root, it is important to
have a document available to the users listing the executables they have
access to (such as doc/helpdir/bin - accessible by 'help bin').
Choosing the programs that go into bin/ is not particularly easy, and making
a mistake can leave holes in the security. This is the main reason that
there is a default bin/ set up by the installation program. Programs that
go into bin/ must satisfy the following:
1) Access ONLY files given to the program as arguments
2) Cannot change (certain) environment variables
2a) Do Shell escapes (!) not according to the SHELL environment variable
2b) Invoke an editor other than the one specified by the EDITOR variable
4) Do NOT use the real login of the account running the mud in any way
5) Do NOT chdir
To discuss these in more detail:
1) Access ONLY files given to the program as arguments
Many programs violate this rule. As mentioned before, the only way wsh
can stop access of files not allowed by the mud security is on the
command line when they type the executable in. An example of a problem
with this is 'vi.' To abuse this, the user could invoke 'vi' without
any arguments (or on a file they can write) and then do either a :r
or a :w, giving them access to any files the account running the wsh
has access to. One major breach would be to open a file and then use it
to write to the .rhosts file of the account running the wsh.
The remedy for this required picking up a copy of a 'vi' clone (since
the source code for 'vi' is not in public domain) and then editing
it so it could not do :w or :r with arguments.
2) Cannot change environment variables
The wsh security depends upon a few environment variables, such as
WSHLOGIN, SHELL and EDITOR. If any program can change these (such as 'env')
then the security can be breached. For example, if WSHLOGIN is set
to another login name, they can then become that login by typing 'wsh'
to get a new wsh (or by doing a shell escape.) If they can change
the SHELL variable you are in even worse shape, they can change it to
something like /bin/csh and then any shell escapes they do will not
be bound by the wsh (as in 2a). All changes to the environment variables
should be done inside the wsh (which has a list of environment variables
that it won't let the user change)
2a) Do Shell escapes (!) not according to the SHELL environment variable
The wsh sets the SHELL variable to the wsh, so that shell escapes will
still go through the wsh. Some programs OVERRIDE this and specifically
call a set shell, such as /bin/sh. One example of this is splitvt, the
split screen utility that is a suggested bin/ executable - earlier versions
of this used to use /bin/sh regardless of the $SHELL var. Fortunately
this has been changed.
2b) Invoke an editor other than the one specified by the EDITOR variable
I have only run into one program so far that does this, 'more.' If you
look at the help for more, under the 'v' key it has (with the proper
path for vi):
v Start up /usr/ucb/vi at current line
If the user can run vi, then they can access files other than the ones
given on the command line (see #1) As an alternative to 'more' I have
edited the source for 'less' (less is more :) to make it secure by wsh
standards. ('less' and 'elvis' (the vi clone) and other source code
is also available either as a separate package or in the binsrc/ directory)
4) Do NOT use the real login of the account running the mud in any way
Examples are 'mail' and 'rlogin.' With mail, they could send mail as the
account running the wsh (not that mail is hard to forge, but.. ;)
rlogin is even worse, they can use it to try to login to the account running
the wsh either on another machine (by .rhosts) or to the same machine (some
systems will not ask for a password to login to the same machine). Even if
they can't do this, they can login elsewhere and hack, and if they are
caught, you get the blame, and that is bad, eh?
5) Do NOT chdir
I haven't found many programs that do this, one example is 'ftp' which
has the 'lcd' command, but 'ftp' violates almost every other rule I have
listed, so this is the least of its concerns. Even so, if you include
such a program, this will seriously jeapordize your security, since the
wsh works by staying in the fake root and referencing all files from there
(see the technical chapter)
I often get asked about 'emacs.' emacs is an example of a program that
also violates just about every security rule here. Unless a real emacs wiz
wants to try to change the source to emacs or an emacs clone so that
it is wsh secure, then emacs will not be available. (Even if someone
did I would still be skeptical of it since they would most likely have
forgotten SOMETHING that creates a security hole)
These are the main rules that cover most types of programs, but there are
still obscure security problems that can come up with some programs, for
example, if the wsh didn't resolve path around links properly, the 'ln'
program could give the user access to files they shouldn't have access to.
It is *very* important to realize that although the wsh is not fooled by
links, most mud drivers are. This makes 'ln' unsecure, because they
can create a link in the wsh that they wouldn't be able to use in the
wsh, but then go ahead and use it inside of the driver.
Another example is an obscure bug with 'ls.' Using 'ls -R' the user can
see files they wouldn't normally have access to, either by using ls -R
to go through links which they normally wouldn't be able to go through
or by listing the files in a directory that is normally unaccessible
because of a directory removed with the '-'
Since this only allows the listing of files, I have left 'ls' in. If
this is a security problem for you, you might want to take it out
and code a replacement.
The most important thing to remember is that if you are ever in doubt,
or if you aren't fully aware of all the capabilities of a program, then
DON'T install it. You could very well regret it, and then you can't come
running to me. ;)
Some programs that compromise security
--------------------------------------
If you install these programs, you will make it possible for users to
get around wsh security. This is *FAR* from being a complete list.
Any compiler (gcc, cc, ...)
Any shell (sh, tcsh, ...)
Any unmodified editor (vi, emacs, etc..)
ftp
tar
(I will add more to this list later)