[lug] replacing login shell

[D. Stimits]

Hugh Brown wrote:
> 
> "D. Stimits"
> >
> > Hugh Brown wrote:
> > >
> > > On Wed, 2002-06-26 at 16:24, D. Stimits wrote:
> > > > One thing many people don't seem to realize (not talking about BLUG, but
> > > > unrelated experiences) is that a shell can be almost any program that
> > > > accepts stdin. If you look in /etc/, files "shells" and "passwd", you
> > > > can add different programs to become a login. A very long time ago, I
> > > > once added a MUD as the login shell to a few users I wanted to chat with
> > > > (and you could do this with an IRC client as well). If you were to get
> > > > the source to the ssh client, and hard wire it to a specific IP address,
> > > > and possibly disable a few things, you'd be much more secure than with a
> > > > script that can be suspended (let's say you have the script secure, then
> > > > you would still have the ssh problems, so having only ssh is not a
> > > > penalty compared to script controlled ssh). One thing that makes me
> > > > suggest hard waring is that you need to pass arguments to ssh client...I
> > > > would hard code it as needed, make it not accept arguments, and call it
> > > > something like "ssh-shell", then add it to /etc/shells, and alter given
> > > > login names to have this as the default shell (and if this is the case,
> > > > they will find it difficult to chsh to a non-ssh shell).
> > > >
> > > > D. Stimits, stimits at idcomm.com
> > >
> > > I realize this is a general comment, but I am wondering what ssh
> > > problems there could be, in this specific case.  I suspend, but I don't
> > > get anything but another telnet prompt, I can't run chsh.  I want to
> > > know if there is some way of bypassing my set up, but I can't find one
> > > (I'm probably just ignorant).
> > >
> > > Hugh
> >
> > I have never tried, but if you use a shell script, it should generally
> > be able to do things with environment variables, or to simply kill it
> > before the shell gets far enough along, and have it do some alternative
> > behavior. Unless it is some form of a secure shell, perhaps in a chroot
> > environment, I would not consider it moderately secure (it should fool
> > the average guy, but not necessarily someone who knows something about
> > shells). Having one less program in the path of dominoes is a security
> > bonus.
> >
> > D. Stimits, stimits at idcomm.com
> 
> Anyone have any specifics?  I really would like to be able to say with some
> assurance that this will work in a secure way.  The shell script only has
> two commands a trap that traps signals 123 and the telnet command.  I am
> the average guy in the above scenario.  I would like to take strides toward
> the more capable than average guy.

For this I would post on comp.os.linux.security, and ask. Keep in mind
that the commands to trap signals might not occur as fast as an attacker
could send the signals...the bash script is not "atomic", it does not
force all or nothing, or at least I don't see the guarantee (cutting out
any script languages means cutting out their weaknesses). Plus you have
all vulnerabilities of the bash interpreter itself being exposed to
remote attackers, one no longer has to have a local login to reach it.
Although I can't give you examples, I think someone from
comp.os.linux.security probably could, almost everything that is subject
to environment variables and extreme flexibility has such a flaw. If you
had the source rpm and are running from RH, it wouldn't be all that hard
to hard code the argc/argv values and bypass the whole mess (then again,
you might find other weaknesses, but it sounds like any ssh client
weaknesses are already going to be there regardless of bash front ends).

D. Stimits, stimits at idcomm.com