[658] in linux-security and linux-alert archive
Re: [linux-security] sliplogin hole explanation
daemon@ATHENA.MIT.EDU (Robert Mark Waugh)
Thu Apr 4 15:02:10 1996
To: linux-security@tarsier.cv.nrao.edu
In-Reply-To: Your message of "Sun, 31 Mar 1996 22:55:00 +0400."
<m0u3SHw-000RocC@hole.botik.ru>
Date: Tue, 02 Apr 1996 10:54:49 -0500
From: Robert Mark Waugh <gh@utkux.utcc.utk.edu>
--------
> In message <m0u2pHl-000HRgC@monad.swb.de> Olaf Kirch writes:
>
> >
> >You then log into your regular slip account, which executes sliplogin as
> >your login shell. Sliplogin, in turn, runs the /etc/slip.login shell
> >script using bash. At startup, bash evaluates *and expands* ENV to
> >obtain the name of a startup file to use instead of .bashrc, and
> >faithfully executes /evil/command.
This security hole is easily avoided. When you compile bash, be
sure to compile it with RESTRICTED_SHELL configured (config.h).
Then, simple instead of invoking bash, invoke rbash or bash -r.
This disables the ability for the user to:
1. cd
2. output redirection that could possibly be destructive
3. assign a new value to shell, env, or path
4. specify any pathname with / in the path. This restricts them to cwd
commands.
5. using the exec builtin
You then setup the PATH and other such things to do what you need it to do
in their .bashrc. You can also specify in the shell entry specific resources
to be loaded avoiding system defaults. This avoids the need to create
specialized login shells that "zap" the passed environments, which is a bad
idea if you have differing systems that aren't compatable on a binary level.
You also might consider developing a heirarchal group algorithm, which,
since standard UNIX doesn't handle nested group memberships, can be painful,
yet, can provide excellent security procedures.
--
===================================================================
| Robert Mark Waugh | gh@utkux.utcc.utk.edu | Research Technology |
oink.
